# Risk Register: Drop — Fintech Payment App

# Risk Register: Drop — Fintech Payment App

> **Project:** Drop — Remittance + QR Payments
> **Version:** 1.1
> **Date:** 2026-02-23
> **Author:** John (AI Director)
> **Status:** Active
> **Reviewers:** Alem Bašić (CEO)

## Document History
| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 0.1 | 2026-02-08 | legal agent + finance agent | Initial 2-round risk identification |
| 1.0 | 2026-02-11 | John | Added technical risks from security audit |
| 1.1 | 2026-02-23 | John | Closed resolved risks; updated statuses |

---

## 1. Risk Identification Methodology

**Identification Methods Used:**
- [x] 2-round multi-agent analysis (8 agents: legal, finance, security, dev, marketer, data-engineer, product, nicksaraev)
- [x] Security audit (2026-02-11, John — 1,102 lines of API code reviewed)
- [x] Regulatory risk checklist (PSD2, AML, GDPR, DORA — gap analysis in security/COMPLIANCE.md)
- [x] Business case risk matrix (zica-business-case-v2.md section 10)
- [x] Assumption analysis (project charter)

**Initial Risk Assessment Date:** 2026-02-08
**Next Scheduled Review:** 2026-03-01 (sprint planning)
**Risk Owner:** John (AI Director)

---

## 2. Risk Categories

| Category | Description | Common Examples |
|----------|-------------|----------------|
| **Technical** | Technology failures, integration issues, performance, security | JWT secrets, SQLite limits, API race conditions |
| **Resource** | Team availability, skill gaps, single points of failure | Alem sole decision-maker, AI cost overruns |
| **External** | Third-party dependencies, regulatory changes, market shifts | BaaS partner, Finanstilsynet, Vipps competition |
| **Financial** | Budget overruns, payment delays, cost estimates | Grant approval delay, marketing burn |
| **Regulatory** | Compliance failures, licence requirements, penalties | PSD2 licence, AML, GDPR, PCI-DSS |
| **Quality** | Defect rate, technical debt, process failures | Security vulnerabilities, untested integrations |

---

## 3. Risk Probability & Impact Scale

### 3.1 Probability Scale

| Level | Score | Definition |
|-------|-------|------------|
| Very Low | 1 | < 10% chance |
| Low | 2 | 10–30% chance |
| Medium | 3 | 30–50% chance |
| High | 4 | 50–70% chance |
| Very High | 5 | > 70% chance |

### 3.2 Impact Scale

| Level | Score | Schedule Impact | Financial Impact |
|-------|-------|----------------|-----------------|
| Negligible | 1 | < 1 day | < 1% budget |
| Minor | 2 | 1–3 days | 1–5% budget |
| Moderate | 3 | 3–7 days | 5–10% budget |
| Major | 4 | 1–2 weeks | 10–20% budget |
| Critical | 5 | > 2 weeks | Project failure |

### 3.3 Risk Matrix

| Score | Risk Level | Response Required | Escalation |
|-------|-----------|-------------------|------------|
| 1–4 | LOW | Monitor monthly | PM awareness |
| 5–9 | MEDIUM | Active mitigation plan | John awareness |
| 10–14 | HIGH | Immediate action + weekly review | John escalation |
| 15–25 | CRITICAL | Emergency response | John + Alem |

---

## 4. Risk Appetite Statement

**Overall Risk Appetite:** LOW (fintech — money movement requires high safety standards)

| Risk Category | Appetite | Rationale |
|--------------|----------|-----------|
| Technical (security) | Very Low | Financial app — zero tolerance for data breaches |
| Regulatory | Very Low | GDPR, PSD2, AML violations have criminal penalties |
| Financial | Low | Fixed budget; overruns require Alem approval |
| External (BaaS) | Medium | Modular architecture allows provider swap |
| Timeline | Medium | Some schedule flexibility acceptable |
| Competition | High | Market risk accepted; innovation is our moat |

---

## 5. Active Risk Register

| ID | Risk Description | Category | Prob (1-5) | Impact (1-5) | Score | Response Strategy | Owner | Status | Date Identified |
|----|-----------------|----------|------------|-------------|-------|-------------------|-------|--------|-----------------|
| R-001 | BaaS partner (Swan or SpareBank1) not confirmed — blocks Phase 2 Open Banking integration | External | 4 | 5 | 20 | Mitigate | Alem | Mitigating — SpareBank1 pitched; Swan backup | 2026-02-08 |
| R-002 | Finanstilsynet PISP/AISP registration delayed beyond planned timeline | Regulatory | 4 | 5 | 20 | Mitigate | Alem + Legal | Open — not started | 2026-02-08 |
| R-003 | Security breach before production hardening complete | Technical | 2 | 5 | 10 | Mitigate | John | Mitigating — audit done; 8 critical fixes tracked | 2026-02-11 |
| R-004 | Vipps launches competing remittance feature | External | 3 | 4 | 12 | Accept | Alem | Monitoring | 2026-02-08 |
| R-005 | Slow merchant adoption — QR revenue below projection | External | 3 | 3 | 9 | Mitigate | Alem | Open — door-to-door strategy planned | 2026-02-08 |
| R-006 | Hardcoded JWT_SECRET fallback active in production | Technical | 2 | 5 | 10 | Mitigate | John | Mitigating — fix tracked in Phase 0.5 | 2026-02-11 |
| R-007 | CVV/card data exposed via GET API endpoint (PCI-DSS violation) | Regulatory | 2 | 5 | 10 | Mitigate | John | Mitigating — last_four only; fix in Phase 0.5 | 2026-02-11 |
| R-008 | SQLite single-writer bottleneck at 200+ concurrent users | Technical | 2 | 3 | 6 | Accept | John | Accepted for MVP; PostgreSQL migration planned | 2026-02-13 |
| R-009 | Alem is sole human decision-maker — decision bottleneck | Resource | 3 | 3 | 9 | Mitigate | Alem | Mitigating — decisions logged in comms/decisions/ | 2026-02-08 |
| R-010 | KYC mock in production — AML compliance not active | Regulatory | 2 | 5 | 10 | Mitigate | John | Open — Sumsub production required before real money | 2026-02-13 |
| R-011 | No real BankID — DOB proxy insufficient for SCA | Technical / Regulatory | 2 | 4 | 8 | Mitigate | John | Open — Phase 1 is demo only; BankID in Phase 2 | 2026-02-13 |
| R-012 | In-memory rate limiter resets on process restart — brute force risk | Technical | 2 | 4 | 8 | Mitigate | John | Mitigating — DB-backed rate limits in Phase 0.5 | 2026-02-11 |
| R-013 | No CSRF protection on state-changing API endpoints | Technical | 2 | 4 | 8 | Mitigate | John | Mitigating — CSRF middleware in Phase 0.5 | 2026-02-11 |
| R-014 | Cash flow gap if Innovasjon Norge grant delayed | Financial | 3 | 3 | 9 | Mitigate | Alem | Monitoring — AI costs keep burn < 10K/month | 2026-02-08 |
| R-015 | Race condition on concurrent remittance transactions (double-spend) | Technical | 2 | 5 | 10 | Mitigate | John | Mitigating — per-user transaction lock implementation | 2026-02-11 |

---

## 6. Risk Response Strategies

| Risk ID | Strategy | Response Actions | Contingency Plan |
|---------|----------|-----------------|------------------|
| R-001 | Mitigate | 1. SpareBank1 pitch submitted; 2. Swan evaluated as backup; 3. Modular BaaS interface in architecture | If neither works: explore Wio Bank, Finom, Treezor |
| R-002 | Mitigate | 1. Engage external legal advisor for Finanstilsynet process; 2. Apply early; 3. Operate under bank partner licence initially | If delayed: launch in limited beta under partner licence |
| R-003 | Mitigate | 1. Security audit complete; 2. Phase 0.5 sprint fixes 8 critical issues; 3. No real money in MVP | If breach occurs: incident response plan in security/incident-response.md |
| R-004 | Accept | Monitor Vipps announcements monthly; accelerate community adoption | Emphasise 0.5% vs Vipps fees; focus on trust advantage |
| R-005 | Mitigate | 1. Door-to-door onboarding; 2. 0% fee for first 3 months; 3. 200-merchant target Month 12 | Adjust fee structure; focus on high-volume corridors |
| R-006 | Mitigate | 1. JWT_SECRET required env var — fail fast; 2. Secrets via Vaultwarden | Rotate secrets immediately; force re-auth |
| R-007 | Mitigate | 1. Remove CVV from GET response; 2. Store only last_four + token_ref; 3. Tokenisation via card partner | Suspend cards feature until fixed |
| R-010 | Mitigate | 1. Sumsub integration contract; 2. Mock clearly gated by feature flag; 3. No real money until KYC live | Suspend onboarding until KYC active |
| R-015 | Mitigate | 1. Per-user transaction lock (in-process); 2. DB-level constraint as backup; 3. PostgreSQL advisory locks in Phase 2 | Suspend concurrent transactions; queue-based processing |

---

## 7. Risk Heat Map

```mermaid
quadrantChart
    title Drop Risk Heat Map — 2026-02-23
    x-axis Low Impact --> High Impact
    y-axis Low Probability --> High Probability
    quadrant-1 "CRITICAL — Immediate Action"
    quadrant-2 "HIGH — Active Management"
    quadrant-3 "LOW — Monitor"
    quadrant-4 "MEDIUM — Watch"
    R-001 (BaaS partner): [1.0, 0.8]
    R-002 (Finanstilsynet): [1.0, 0.8]
    R-004 (Vipps): [0.8, 0.6]
    R-003 (Security): [1.0, 0.4]
    R-006 (JWT): [1.0, 0.4]
    R-007 (CVV): [1.0, 0.4]
    R-015 (Race condition): [1.0, 0.4]
    R-009 (Alem bottleneck): [0.6, 0.6]
    R-014 (Cash flow): [0.6, 0.6]
    R-008 (SQLite): [0.6, 0.4]
```

---

## 8. Escalation Thresholds

| Threshold | Action | Responsible | Timeframe |
|-----------|--------|-------------|-----------|
| Any new risk Score ≥ 15 | Escalate to Alem + John | John | Within 4 hours |
| Any existing risk score increases by ≥ 5 | Escalate to John | John | Within 24 hours |
| > 3 risks at Score ≥ 10 simultaneously | Emergency risk review | John + Alem | Within 48 hours |
| Risk triggers contingency plan | Notify all stakeholders | John | Immediately |
| Risk causes milestone slip > 3 days | Formal change request | John | Within 24 hours |

---

## 9. Review Schedule

| Frequency | Activity | Participants | Output |
|-----------|----------|-------------|--------|
| Weekly (Sprint Planning) | Review all active risks, update scores | John | Updated register |
| Sprint Retrospective | New risks identified; closed risks archived | John | New risks logged |
| Monthly | Full register review + heat map | John, Alem | Risk report |
| Milestone | Risk review before go/no-go | John, Alem | Go/no-go input |

### Review Log

| Date | Reviewer | Risks Reviewed | New Added | Closed | Key Changes |
|------|----------|---------------|-----------|--------|-------------|
| 2026-02-08 | legal + finance agents | — | 6 | 0 | Initial identification |
| 2026-02-11 | John (security audit) | 6 | 10 | 0 | Added R-006 through R-015 |
| 2026-02-23 | John | 15 | 0 | 5 | Closed R-C01 to R-C05; updated statuses |

---

## 10. Closed Risks Archive

| ID | Risk Description | Resolution Type | Resolution Notes | Date Closed |
|----|-----------------|----------------|-----------------|-------------|
| R-C01 | Wallet/balance model requires e-money licence | Avoided | Pivoted to PSD2 pass-through model (ADR-003) | 2026-02-12 |
| R-C02 | FontelePay tightly coupled to Drop — regulatory risk | Avoided | Separated to own module (ADR-002) | 2026-02-12 |
| R-C03 | Zica brand name has cultural sensitivity | Avoided | Rebranded to Drop (Alem decision 2026-02-09) | 2026-02-09 |
| R-C04 | "Banking" language in UI creates regulatory exposure | Mitigated | Removed all "banking" references from UI (task #197) | 2026-02-09 |
| R-C05 | SHA-256 password support creates rainbow table vulnerability | Mitigated | SHA-256 support removed; bcrypt-only policy enforced | 2026-02-13 |

---

## Approval

| Role | Name | Date | Signature |
|------|------|------|-----------|
| Author | John (AI Director) | 2026-02-08 | Approved (AI) |
| Reviewer | John (AI Director) | 2026-02-23 | Reviewed |
| AI Director (John) | John | 2026-02-23 | Approved |
| Project Sponsor | Alem Bašić | TBD — requires review | |