eWallet Technical Analysis

Part 01

Current Architecture

As-built system map based on full codebase review. 9 Django apps, 466-file React Native mobile app, and ~300-file PHP back-office portal. Last commit: November 2025.

What works well

JWT authentication (5-min access / 15-day refresh with blacklist). Atomic transactions + select_for_update on DuitNow flows. PIN lockout (3 attempts → suspend). Step-up auth for large amounts. Audit trail logging. Live DuitNow / NPG / Zoloz eKYC integrations. ~1,360 commits of history. The duitnow_balance_handler.py module is well-structured with proper available_balance vs current_balance separation and daily limit aggregation.

Django Backend

3.2 / Python 3.6 · 9 apps (accounts, transactions, otps, reload, bw, webapi, school, refs, logs) · ~1,360 commits · Last active Nov 2025 (7 months dark). JWT + sessions. Real money logic lives here.

React Native App

Expo · JavaScript → partial TypeScript migration. 466 files. Consumer + merchant wallets. JWT stored in Redux (not secure storage).

PHPRunner Portal

~300 PHP files. Low-code generated. Ops, finance, compliance. Hardcoded credentials. Not auditable. Should be internal-network only.

Part 02

Technical Findings

15 findings from full codebase review. Severity rated: Critical (fix now) → High (fix this sprint) → Medium (fix this quarter).

2 Critical 6 High 7 Medium 1 Well Done

#	Area	Finding	Severity
1	Security	`.env`, `privatekey.pem`, and `privatekey_pkcs8.pem` are committed and tracked in git. Anyone with repo access has the wallet signing keys.	CRITICAL
2	Security	DB credentials, SMTP password, and JWT secret hardcoded in PHP portal source code.	CRITICAL
3	Runtime	Python 3.6.15 — EOL December 2021. Zero security patches available. Every known Python vuln since 2021 is unpatched.	HIGH
4	Security	`pycrypto 2.6.1` in requirements — abandoned crypto library with known CVEs. `pycryptodome` (the maintained fork) is already present, so this is just dead weight + open CVEs.	HIGH
5	Testing	Only `accounts/tests.py` has ~31 lines of tests. Every other app is an empty stub. Zero test coverage on balance and transaction logic — changes cannot be safely made.	HIGH
6	Money Model	`wallet.current_balance` is overwritten on every transaction. Confirmed: `payer_post_balance = payer_wallet.current_balance - amount`. If a crash occurs mid-transaction, balance drifts permanently with no way to reconstruct from first principles.	HIGH
7	Security	OTP stored as plaintext `char` field in `trx_otp` table. Should be hashed.	HIGH
8	Mobile	JWT tokens stored in Redux state (in-memory). Should be in Keychain (iOS) / Keystore (Android) — OS-level secure storage.	HIGH
9	Code Quality	NPG gateway logic (`npgsenddata.py`) duplicated across 4 apps: `bw/` (502 lines), `transactions/` (275), `reload/` (116), `webapi/` (27). All have diverged. A bug fix must be applied 4 times or the system is inconsistent.	MEDIUM
10	Code Quality	`duitnow_views.py` = 2,575 lines. `accounts/register.py` = 911 lines. God files — untestable and unmaintainable.	MEDIUM
11	Data	`profile_pic` stored as `BinaryField` in the main user table. Profile images in the transaction DB inflate row size and slow all user queries.	MEDIUM
12	Platform	Django 3.2 extended support ended April 2024. Most pip dependencies are several years old with published advisories.	MEDIUM
13	Mobile	Partial TypeScript migration — newer screens are `.tsx`, legacy are `.js/.jsx`. Referenced type definitions removed. Type errors fail silently in production builds.	MEDIUM
14	Mobile	Debug `console.log` statements throughout mobile codebase — leaking transaction state and user data to device logs in production.	MEDIUM
15	Ops	`# KENA SET BALIK ALL SETTINGS` comment in `config/settings/prod.py` line 13 — evidence of manual config drift between dev and prod environments.	MEDIUM

One thing done right: duitnow_balance_handler.py

This is the newest, best-written module in the codebase. It uses proper available_balance vs current_balance separation (hold pattern), atomic transactions with select_for_update, daily limit aggregation inclusive of pending states, and min/max guards. Whoever authored this module understood financial system design. This person is the key technical asset to identify and engage.

Part 03

eWallet 2.0 — What to Build

Six core changes that must happen, plus the recommended tech stack and delivery phases. Total timeline: 11–17 months with a dedicated team.

1 Double-Entry Ledger

Current mutable balance can drift permanently. Every transaction in 2.0 must produce 2 immutable entries (debit + credit). Balance is derived by summing entries — never written directly. Store as integer sen (1234 = RM12.34). No floats. This is the foundational change that everything else depends on.

2 Secrets Out of Code

Signing keys are compromised right now. Immediate: rotate all keys and remove from git history. Long-term: all secrets via Vault or AWS Secrets Manager. HSM for signing keys — they never leave the HSM. CI secret scanner (gitleaks) blocks any future credential commit.

3 Upgrade Runtime

Python 3.6 has had zero security patches since Dec 2021. Upgrade path: Python 3.11 → Django 4.2 LTS → audit all dependencies with pip-audit. This is a prerequisite for anything else — running on EOL software makes every other security effort moot.

4 Test Coverage on Money Logic

Zero coverage means no change can be made safely. Unit tests required: balance arithmetic, transaction state machine, freeze/deduct/return cycle, negative balance guards, daily limit enforcement. These run on every PR via CI — no merge without green tests.

5 Single Payment Module

NPG gateway logic exists in 4 diverged copies. Extract into one payment_gateway/ service. All apps call it. One bug fix propagates everywhere instead of being applied 4 times (or missed in 3 copies). Same pattern for DuitNow callbacks.

6 Replace PHPRunner Portal

Hardcoded credentials, low-code generated, not auditable. Replace with React + TypeScript admin portal. RBAC, maker-checker on all money actions, full audit view. Uses the same APIs as the mobile app — no separate backend surface.

Recommended Tech Stack

Layer	Choice	Rationale
API Core	Kotlin + Spring Boot	Type-safe, JVM-native, battle-tested in production fintech (GrabPay, Wise, Revolut). Strong async support, excellent PostgreSQL integration. FastAPI (Python 3.11) is a valid fallback for teams with stronger Python fluency — the data model discipline matters more than the language.
Database	PostgreSQL	Real `NUMERIC`, strong constraints, exclusion constraints, logical replication. MySQL has documented floating-point edge cases for financial arithmetic.
Cache / Locks	Redis	Hot balance reads, rate limiting, distributed locks for concurrent wallet operations, idempotency key cache.
Events	Kafka or AWS SQS	Outbox pattern — events published atomically with ledger writes. SQS for simpler start; Kafka when throughput demands it.
Mobile	React Native + TypeScript	Keep existing RN investment. Complete the TypeScript migration fully. Tokens move to Keychain/Keystore.
Back-Office	React + TypeScript	Replace PHPRunner permanently. Same stack as mobile team — no context switch. RBAC and maker-checker built in from day one.
Secrets	AWS Secrets Manager	Never in code, never in env files tracked by git. Rotate without redeployment. HSM for signing keys.
Observability	OpenTelemetry + Grafana	End-to-end tracing on every transaction. "What happened to this transaction?" answerable in seconds, not hours of log digging.

Delivery Phases

P0 Security Triage

1–2 weeks · Starts now

Rotate all committed keys. Remove from git history. Deploy secret scanner. Patch Python CVEs. Restrict PHPRunner to internal network only. Deliverable: no known active exploits.

P1 Ledger Core

2–3 months

Double-entry ledger, idempotency keys, transactional outbox, test harness (≥80% coverage on money logic). This is the foundation — every feature after this is safe to build on.

P2 Rails + Identity

2–3 months

Single payment service (DuitNow / NPG), KYC / liveness re-integration (Zoloz), risk engine and daily limits, BNM compliance reporting.

P3 New Clients

3–4 months

New React Native + TypeScript mobile app and React back-office portal at full feature parity with current system. Tokens in secure storage. Zero PHPRunner dependencies.

P4 Harden

1–2 months

Load testing, penetration test, automated reconciliation between new ledger and legacy data, formal security review. Pre-migration sign-off.

P5 Migration

2–3 months

Parallel run with shadow ledger validation. Phased user cohort cutover (5% → 25% → 100%). Legacy decommission. BNM licence stays with XOX throughout — no re-certification required.

BNM Licence — no disruption

The e-money licence stays with XOX throughout. As long as the licensed entity remains unchanged, re-certification risk is low — but early BNM engagement is recommended to confirm no re-approval is triggered by infrastructure changes. This should be validated with XOX's compliance team before P5 migration begins.

Part 04

AI & Fraud Intelligence Layer

The highest-ROI investment in the 2.0 rebuild. Fraud prevention and AML compliance are BNM obligations — AI turns them from cost centres into competitive advantages.

Fraud & AML — Highest Priority

Real-time transaction scoring on every payment event. ML model trained on XOX's own transaction history — catches account takeovers, mule networks, and reload fraud patterns specific to this user base. AML flagging feeds directly into BNM STR reporting, turning a compliance burden into an automated workflow. Fraud loss prevention typically delivers 3–5× ROI in the first year.

Risk Engine (Credit Scoring)

XOX has 1.5M MVNO subscribers with transaction history and telco behaviour data. A lightweight credit scoring model unlocks BNPL and micro-credit features — new revenue streams that a standalone fintech company cannot access without this distribution. This is the platform play that justifies the 2.0 rebuild cost.

Ops Intelligence

Anomaly detection on daily settlement reconciliation — flags discrepancies before they become audit issues. Predictive top-up prompts based on spending patterns. Churn risk scoring on wallet dormancy. These run passively and surface via the back-office portal — no additional engineering surface required.

Agentic Payments (Phase 2+)

LLM-powered payment intents — natural language instructions that resolve to the correct transaction type. "Pay my Maxis bill" → validates billers, confirms amount, executes. This is the UX differentiator for the next generation of Malaysian e-wallets and positions XOX ahead of Touch 'n Go and Boost on experience.

AI Stack: Built on the Ledger

The double-entry ledger in P1 is the prerequisite for all AI features. Clean, immutable transaction records are the training data. Without the ledger, every ML model is trained on mutable, potentially drifted balances — garbage in, garbage out. The sequence is not optional: Ledger Core → Fraud Model → Credit Scoring → Agentic layer.

Part 05

Recommended Engagement Model

Three phases of engagement — from immediate security triage to long-term technical partnership. The strategic fork (remediation vs. greenfield rebuild) should be decided at the end of P0 with full data.

Immediate — P0 Triage

Rotate compromised keys. Deploy secret scanner. Patch CVEs. 2 weeks, low cost. High trust signal — show up with a fix, not just a proposal.

Medium Term — Tech Partner

Becomes XOX's de facto engineering arm on retainer. Covers maintenance of existing system while P1 ledger core is built in parallel. No service gap.

Long Term — 2.0 Build

Full 2.0 rebuild on outcome-based commercial terms. Retainer baseline + milestone payments tied to phase delivery. Shared upside on cost savings and new revenue enabled by the platform.

06

Remediation vs. Rebuild — Decision Framework

Two credible paths. Different risk profiles. COO decides.

Path A — Targeted Remediation

Timeline6–9 months

Est. CostRM 380k–550k

Risk LevelLower

Team Size3–4 engineers

Fix security vulns, upgrade Python 3.11, extract god-files, add test coverage, migrate off pycrypto. Existing architecture retained — Architecture Review confirms it is fundamentally sound. XOX team can maintain post-handover.

✓ Faster. Lower cost. Less BNM risk.
✗ Mutable ledger remains. Scale ceiling intact.

Path B — Greenfield 2.0 Rebuild

Timeline12–17 months

Est. CostRM 1.1M–1.6M

Risk LevelHigher

Team Size6–8 engineers

Full architectural reset. Kotlin + Spring Boot core, double-entry immutable ledger, Kafka event bus, AI/fraud layer from day one. Built to support 1M+ wallets, open banking APIs, BNPL/credit scoring products.

✓ Unlimited scale ceiling. Full AI/fraud layer.
✗ Longer. Costlier. BNM engagement required early.

Recommendation

Begin with Path A as the immediate engagement — it delivers safety, compliance, and stability within 9 months at manageable cost. Use the remediation phase to assess XOX's growth ambition and transaction volume trajectory. If XOX targets >500k active wallets or open banking product expansion within 24 months, convert to Path B with carry-over work credited. P0 triage applies equally to both paths.

07

Cost Model & Commercial Structure

Indicative ranges. Final scope subject to discovery sprint.

Standard Market Rate vs AI-Native Delivery

Engagement	Duration	Standard Rate	AI-Native Rate	Saving
P0 — Security Triage	2–3 weeks	RM 28k–45k	RM 15k–25k	~40%
Path A — Remediation	6–9 months	RM 380k–550k	RM 260k–380k	~30%
Path B — 2.0 Rebuild	12–17 months	RM 1.1M–1.6M	RM 750k–1.1M	~32%

AI-native advantage: AI tooling compresses scaffolding, test generation, API wiring, and code review cycles by 40–50%. Senior fintech judgement — atomic transaction logic, BNM compliance gates, DuitNow/NPG certification, migration cutover — is not compressed. Timeline savings ~20% on Path B; constraint is compliance + testing cycles, not coding velocity.

Commercial Terms — Proposed Structure

Engagement Structure

· Monthly retainer covers core engineering team

· Milestone payments tied to phase sign-off

· P0 is fixed-fee, no retainer commitment required

· Path B includes outcome-based component (cost savings share)

What's Included

· Full engineering team (dev, QA, DevOps)

· BNM engagement support documentation

· Knowledge transfer to XOX internal team

· 3-month post-launch maintenance window

⚠ All figures are indicative. A 2-week paid discovery sprint (included in P0) will produce a fixed-scope proposal before any long-form commitment is required.

08

P0 — Immediate Engagement Scope

What XOX gets in the first 2–3 weeks. No long-term commitment required.

Security Remediation Package

✓ Rotate all committed secrets (private keys, DB credentials, API tokens)

✓ Implement git-secrets / pre-commit hooks to prevent re-occurrence

✓ Replace pycrypto with cryptography library (patched CVEs)

✓ Full dependency audit — pin all packages, generate SBOM

✓ Document all hardcoded credentials found in PHP back-office

Discovery & Technical Audit Report

✓ Full codebase walkthrough with XOX team

✓ Map all live BNM/DuitNow/NPG integration touchpoints

✓ Identify all double-spend / race condition risk surfaces

✓ Document current transaction volumes, user counts, peak load

✓ Deliver fixed-scope proposal for Path A or B within 2 weeks

P0 Outcome

At the end of P0, XOX receives: (1) a secured codebase with no known exposed credentials, (2) a full written technical audit report, (3) a fixed-scope + fixed-price proposal for the chosen path. XOX can walk away after P0 with no further obligation — and a meaningfully safer live system.

09

Risk Register

Top risks across both paths with proposed mitigations.

Migration Cutover Failure

HIGH · Path B

Wallet balance mismatch between legacy and new system at cutover. BNM-regulated — any reconciliation error is a compliance event.

Mitigation: Cohort migration model — never cut a cohort until opening ledger balance reconciles to the cent. Parallel-run period minimum 4 weeks.

BNM Re-certification Risk

HIGH · Path B

Material changes to licensed system may require BNM notification or re-certification. Timelines are regulator-controlled and can cause significant delay.

Mitigation: Early BNM engagement (pre-P2). Keep XOX as licensed entity throughout — no change of control on the licensed entity.

Scope Creep / Timeline Slip

HIGH · Both Paths

Greenfield rebuilds consistently expand in scope. Feature additions mid-build are the primary driver of 17-month → 24-month slippage.

Mitigation: Feature freeze after P1 scope sign-off. Change requests priced separately. Milestone payments create natural scope checkpoints.

Knowledge Transfer Gap

MEDIUM · Both Paths

XOX currently has no internal engineering team. Post-delivery dependency on Fast Tech if no internal capability is built in parallel.

Mitigation: Structured knowledge transfer sessions throughout. XOX hiring plan for 2–3 internal engineers recommended by M6. Documentation-first culture baked into delivery SLA.

DuitNow / NPG Rail Certification

MEDIUM · Path B

New system requires re-certification with DuitNow and NPG payment rails. Certification windows are fixed and may gate go-live dates.

Mitigation: Begin certification process at P3 (parallel ledger build). 6-month lead time budgeted into timeline.

10

Proposed Team Composition

Fast Technology delivery team — scales with chosen path.

Path A — Remediation Team (3–4)

Technical Lead / Architect×1

Senior Backend Engineer (Django/Python)×2

DevOps / Security Engineer×1

Path B — 2.0 Build Team (6–8)

Technical Lead / Architect×1

Senior Backend Engineer (Kotlin)×2

Mobile Engineer (React Native)×1

ML / Fraud Engineer×1

DevOps / Infrastructure×1

QA Engineer×1

Project Manager×1

XOX eWalletTechnical Analysis

XOX eWallet
Technical Analysis