Threat Model: Pay-Outs

Status: Draft | Owner: Security Team | Last Updated: 2026-04-03 Methodology: STRIDE | Scope: Disbursement flow end-to-end

Overview

STRIDE threat analysis for Simpaisa's Pay-Out (disbursement) product. Covers bank transfers and mobile wallet credits across PK, BD, NP, and IQ. Pay-Outs are high-value targets — successful exploitation results in direct financial loss as funds leave the platform irrevocably.

---

Data Flow Diagram

┌──────────┐    HTTPS     ┌──────────┐    gRPC     ┌───────────┐
│ Merchant │─────────────▶│ KrakenD  │────────────▶│  Pay-Out  │
│ Portal / │   (signed)   │ Gateway  │  (mTLS)     │  Service  │
│   API    │              └──────────┘             └─────┬─────┘
└──────────┘                   │                        │
                               │                        │ Temporal
                               ▼                        │ workflow
                          ┌──────────┐                  ▼
                          │  Auth    │           ┌───────────┐
                          │ Service  │           │  Balance  │
                          └──────────┘           │  Service  │
                                                 └─────┬─────┘
                                                       │ reserve
                                                       ▼
                          ┌──────────┐           ┌───────────┐
                          │ Benefic. │           │  Channel  │
                          │ Registry │           │  Adapter  │
                          └──────────┘           └─────┬─────┘
                                                       │
                                                       ▼
                          ┌──────────┐           ┌───────────┐
                          │ SurrealDB│◀──────────│ Settlement│
                          │          │           │  Recon    │
                          └──────────┘           └───────────┘

---

Attack Surfaces

Surface	Entry Point	Trust Level
Disbursement API	KrakenD gateway	Authenticated
Balance queries	Internal balance service	Trusted (mTLS)
Beneficiary registration	Merchant portal / API	Authenticated
Batch file upload	Merchant portal	Authenticated
Settlement files	Channel→Simpaisa SFTP/API	External

---

STRIDE Analysis

S — Spoofing

ID	Threat	Likelihood	Impact
S-PO-1	Unauthorised disbursement (stolen signing key)	Medium	Critical
S-PO-2	Spoofed batch approval (bypass 4-eyes)	Low	Critical

S-PO-1: Stolen signing key - Attack: Attacker obtains merchant's HMAC signing secret and initiates fraudulent disbursements to attacker-controlled accounts. - Mitigation: Signing secrets stored in HSM-backed vault. Key rotation every 90 days. Velocity checks: unusual disbursement patterns trigger hold. Dual-approval for disbursements above threshold (configurable per merchant). - Residual risk: Insider threat with both API key and signing secret.

S-PO-2: Bypassed batch approval - Attack: Single compromised user account creates and approves a batch disbursement (circumventing 4-eyes principle). - Mitigation: createdBy and approvedBy must be different user IDs. System enforces separation at service layer. Batch approval requires MFA re-authentication.

T — Tampering

ID	Threat	Likelihood	Impact
T-PO-1	Balance overdraft via race condition	Medium	Critical
T-PO-2	Settlement file tampering	Low	High
T-PO-3	Beneficiary account swap	Medium	Critical

T-PO-1: Balance overdraft (race condition) - Attack: Multiple concurrent disbursement requests processed simultaneously, each passing balance check independently, resulting in total disbursements exceeding available balance. - Mitigation: Atomic balance reservation using SurrealDB transactions with serialisable isolation. Temporal workflow ensures sequential balance check → reserve → execute. Optimistic locking with version field on balance record. → ADR-028 (Balance Management)

T-PO-2: Settlement file tampering - Attack: Attacker intercepts settlement file from channel provider, modifying transaction statuses or amounts. - Mitigation: Settlement files signed by provider (PGP/GPG). Reconciliation compares settlement against internal ledger — discrepancies flagged for manual review. SFTP with mutual authentication.

T-PO-3: Beneficiary account takeover - Attack: Attacker modifies an existing beneficiary's bank account details to redirect future disbursements. - Mitigation: Beneficiary account changes require re-verification. 24-hour cooling period on account detail changes. Notification sent to merchant admin on any beneficiary modification. Audit trail on all changes.

R — Repudiation

ID	Threat	Likelihood	Impact
R-PO-1	Disputed disbursement authorisation	Medium	High
R-PO-2	Batch approval attribution unclear	Low	Medium

R-PO-1: Disputed authorisation - Attack: Merchant claims they did not authorise a disbursement. - Mitigation: Full request payload with HMAC signature stored. IP address and user agent logged. Temporal workflow history provides immutable execution audit trail.

R-PO-2: Batch approval gaps - Mitigation: Batch audit trail includes createdBy, approvedBy, timestamps, and MFA verification records. All stored in immutable AuditEntry.

I — Information Disclosure

ID	Threat	Likelihood	Impact
I-PO-1	Beneficiary account details leaked	Medium	High
I-PO-2	Balance information exposure	Low	Medium

I-PO-1: Beneficiary data leak - Attack: API response or logs expose full beneficiary bank account numbers. - Mitigation: Account numbers masked in API responses (show last 4 only). Full numbers accessible only via dedicated secure endpoint with additional authentication. PII masking in logs.

I-PO-2: Balance exposure - Mitigation: Balance endpoints restricted to authorised roles only. Balance amounts not included in webhook payloads. Response caching disabled for balance queries.

D — Denial of Service

ID	Threat	Likelihood	Impact
D-PO-1	Balance lock exhaustion	Medium	High
D-PO-2	Channel adapter flooding	Low	Medium

D-PO-1: Balance lock exhaustion - Attack: Attacker creates many small disbursement requests that reserve balance but never complete, effectively locking all merchant funds. - Mitigation: Balance reservations expire after configurable TTL (default 15 minutes). Maximum concurrent pending disbursements per merchant. Stale reservation cleanup via Temporal timer.

D-PO-2: Channel flooding - Mitigation: Circuit breaker per channel adapter. Queue-based submission with backpressure. Per-merchant throughput limits.

E — Elevation of Privilege

ID	Threat	Likelihood	Impact
E-PO-1	Cross-merchant disbursement	Low	Critical
E-PO-2	Finance role escalation to admin	Low	High

E-PO-1: Cross-merchant disbursement - Attack: Attacker manipulates merchantId to disburse from another merchant's balance. - Mitigation: merchantId derived from authenticated session — never from request body. Balance service validates merchantId against authenticated identity. Tenant isolation enforced at every service boundary.

E-PO-2: Role escalation - Mitigation: Role assignment requires manage_roles permission (admin only). System roles are immutable. Role changes produce audit entries and notifications.

---

Risk Matrix

Threat	Likelihood	Impact	Risk Level	Mitigation Status
S-PO-1	Medium	Critical	High	Implemented
S-PO-2	Low	Critical	Medium	Implemented
T-PO-1	Medium	Critical	High	Implemented
T-PO-2	Low	High	Medium	Implemented
T-PO-3	Medium	Critical	High	In progress
R-PO-1	Medium	High	High	Implemented
R-PO-2	Low	Medium	Low	Implemented
I-PO-1	Medium	High	High	Implemented
I-PO-2	Low	Medium	Low	Implemented
D-PO-1	Medium	High	High	Implemented
D-PO-2	Low	Medium	Low	Implemented
E-PO-1	Low	Critical	Medium	Implemented
E-PO-2	Low	High	Medium	Implemented

---

ADR Cross-References

Mitigation Area	Related ADR / Standard
Balance management	ADR-028 Balance Management
API authentication	ADR-017 API Authentication
Tenant isolation	ADR-019 Tenant Isolation
Audit trail	ADR-031 Audit Trail
PII handling	PII-HANDLING-STANDARD
Rate limiting	RATE-LIMITING-POLICY
Secret management	SECRET-MANAGEMENT-STANDARD