Skip to main content

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:

  • 2-round multi-agent analysis (8 agents: legal, finance, security, dev, marketer, data-engineer, product, nicksaraev)
  • Security audit (2026-02-11, John — 1,102 lines of API code reviewed)
  • Regulatory risk checklist (PSD2, AML, GDPR, DORA — gap analysis in security/COMPLIANCE.md)
  • Business case risk matrix (zica-business-case-v2.md section 10)
  • 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

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

No comments to display

Back to top