Skip to main content

Risk Register

Risk Register: {{PROJECT_NAME}}Drop — Fintech Payment App

Project: {{PROJECT_NAME}}Drop — Remittance + QR Payments Version: {{VERSION}}1.1 Date: {{DATE}}2026-02-23 Author: {{AUTHOR}}John (AI Director) Status: Draft | In Review | ApprovedActive Reviewers: {{REVIEWERS}}Alem Bašić (CEO)

Document History

Version Date Author Changes
0.1 {{DATE}}2026-02-08 {{AUTHOR}}legal agent + finance agent Initial draft2-round risk identification
1.02026-02-11JohnAdded technical risks from security audit
1.12026-02-23JohnClosed resolved risks; updated statuses

1. Risk Identification Methodology

Identification Methods Used:

  • Team2-round brainstormingmulti-agent sessionanalysis (Date:8 {{DATE}},agents: Participants:legal, {{PARTICIPANTS}})finance, security, dev, marketer, data-engineer, product, nicksaraev)
  • LessonsSecurity learnedaudit review(2026-02-11, fromJohn previous— projects1,102 lines of API code reviewed)
  • RiskRegulatory categoryrisk checklist (seePSD2, SectionAML, 2)GDPR, DORA — gap analysis in security/COMPLIANCE.md)
  • StakeholderBusiness interviewscase risk matrix (zica-business-case-v2.md section 10)
  • Assumption analysis (see project charter)
  •  Technical spike / proof-of-concept findings

Initial Risk Assessment Date: {{DATE}}2026-02-08 Next Scheduled Review: {{DATE}}2026-03-01 (sprint planning) Risk Owner: {{RISK_OWNER}}John (typicallyAI the Project Manager)Director)

2. Risk Categories

Category Description Common Examples
Technical Technology failures, integration issues, performance, security APIJWT changes,secrets, infrastructureSQLite limits, unknownAPI complexityrace conditions
Resource Team availability, skill gaps, capacitysingle constraintspoints of failure KeyAlem personsole sickdecision-maker, leave,AI agentcost performance degradation
ClientClient-side decisions, availability, requirement volatilityDelayed approvals, changing priorities, unclear requirementsoverruns
External Third-party dependencies, regulatory changes, market shifts APIBaaS deprecation,partner, GDPRFinanstilsynet, change,Vipps competitor launchcompetition
Financial Budget overruns, payment delays, cost estimates UnderestimatedGrant effort,approval currencydelay, exposure,marketing vendor price changeburn
TimelineRegulatory ScheduleCompliance risks,failures, deadlinelicence pressure,requirements, estimation errorspenalties MilestonePSD2 slip,licence, hardAML, deadline,GDPR, dependency delaysPCI-DSS
Quality Defect rate, technical debt, process failures InsufficientSecurity testing,vulnerabilities, rusheduntested delivery, poor documentation
OrganizationalInternal politics, process changes, leadership decisionsReprioritization, team restructure, tool changesintegrations

3. Risk Probability & Impact Scale

3.1 Probability Scale

Level Score Definition Example
Very Low 1 < 10% chance — rare, theoreticalUnknown-unknown
Low 2 10–30% chance — unlikely but possibleHistorical precedent rare
Medium 3 30–50% chance — may occurHas happened on similar projects
High 4 50–70% chance — likely to occurHappens regularly
Very High 5 > 70% chance — almost certainHappened before on this type

3.2 Impact Scale

Level Score Schedule Impact Budget ImpactQualityFinancial Impact
Negligible 1 < 1 day < 1% Minor fix neededbudget
Minor 2 1–3 days 1–5% Some rework neededbudget
Moderate 3 3–7 days 5–10% Significant reworkbudget
Major 4 1–2 weeks 10–20% Deliverable at riskbudget
Critical 5 > 2 weeks > 20%Project failure risk

3.3 Risk Matrix (Probability × Impact)

         IMPACT →
         1(Neg) 2(Min) 3(Mod) 4(Maj) 5(Crit)
P  5(VH) |  5  |  10  |  15  |  20  |  25  |  ← CRITICAL ZONE (≥15)
R  4(H)  |  4  |   8  |  12  |  16  |  20  |
O  3(M)  |  3  |   6  |   9  |  12  |  15  |
B  2(L)  |  2  |   4  |   6  |   8  |  10  |  ← MEDIUM ZONE (5-14)
↑  1(VL) |  1  |   2  |   3  |   4  |   5  |  ← LOW ZONE (≤4)
Score Risk Level Response Required Escalation
1–4 LOW Monitor; reviewMonitor monthly PM awareness
5–9 MEDIUM Active mitigation plan required PMJohn + Tech Leadawareness
10–14 HIGH Immediate action + weekly review PMJohn + Johnescalation
15–25 CRITICAL Emergency response; may stop projectresponse John + Alem

4. Risk Appetite Statement

Overall Risk Appetite: {{LOW |(fintech MEDIUM— |money HIGH}}movement requires high safety standards)

Risk Category Appetite Rationale
Technical (security) MediumVery Low InnovationFinancial requiresapp technical— experimentationzero tolerance for data breaches
RegulatoryVery LowGDPR, PSD2, AML violations have criminal penalties
Financial Low BudgetFixed is fixed;budget; overruns require CEOAlem approval
QualityExternal (BaaS) LowMedium ClientModular satisfactionarchitecture isallows coreprovider to ALAI brandswap
Timeline Medium Some schedule flexibility acceptable if quality maintained
SecurityCompetition Very LowHigh ZeroMarket tolerancerisk foraccepted; data breaches or compliance violations
RegulatoryVery LowLegal exposureinnovation is unacceptableour moat

Maximum Acceptable Risk Exposure: Score ≤ 9 without escalation to John. Escalation Threshold: Any risk scoring ≥ 10 must be reported to John within 24 hours.

5. Active Risk Register

Alem Lead
ID Risk Description Category Prob (1-5) Impact (1-5) Score Response Strategy Owner Trigger IndicatorsStatus Date IdentifiedReview Date
R-001 {{RISK_DESCRIPTION}}BaaS partner (Swan or SpareBank1) not confirmed — blocks Phase 2 Open Banking integration TechnicalExternal {{1-5}}4 {{1-5}}5 {{SCORE}}20 Mitigate {{OWNER}}Alem {{TRIGGER}}Mitigating — SpareBank1 pitched; Swan backup Open{{DATE}}{{DATE}}2026-02-08
R-002 KeyFinanstilsynet clientPISP/AISP contactregistration unavailabledelayed forbeyond approvalsplanned timeline Client3Regulatory 4 12520 Mitigate PM Slow+ email responses; missed meetingsLegal Open — not started {{DATE}}{{DATE}}2026-02-08
R-003 Third-partySecurity APIbreach deprecatesbefore requiredproduction endpointhardening complete ExternalTechnical 2 5 10 Mitigate Tech LeadJohn VendorMitigating changelog;— APIaudit versioningdone; notice8 critical fixes tracked Open{{DATE}}{{DATE}}2026-02-11
R-004 ScopeVipps creeplaunches fromcompeting undiscoveredremittance requirementsfeature Client4312MitigateBA/PMFrequent "small" change requestsOpen{{DATE}}{{DATE}}
R-005Performance targets not met under loadTechnicalExternal 3 4 12 MitigateAccept TechAlem Monitoring2026-02-08
R-005 Slow responsemerchant inadoption dev— testingQR revenue below projectionExternal339MitigateAlem Open — door-to-door strategy planned {{DATE}}{{DATE}}2026-02-08
R-006 {{RISK_DESCRIPTION}}Hardcoded JWT_SECRET fallback active in production Technical 2 5 10 Mitigate John Mitigating — fix tracked in Phase 0.5 Open{{DATE}}{{DATE}}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 Open2026-02-11
R-008 SQLite single-writer bottleneck at 200+ concurrent users Technical 2 3 6 Accept John Accepted for MVP; PostgreSQL migration planned2026-02-13
R-009Alem is sole human decision-maker — decision bottleneckResource339MitigateAlemMitigating — decisions logged in comms/decisions/2026-02-08
R-010KYC mock in production — AML compliance not activeRegulatory2510MitigateJohn Open — Sumsub production required before real money 2026-02-13
R-011 No real BankID — DOB proxy insufficient for SCATechnical / Regulatory248MitigateJohnOpen — Phase 1 is demo only; BankID in Phase 22026-02-13
R-012In-memory rate limiter resets on process restart — brute force riskTechnical248MitigateJohnMitigating — DB-backed rate limits in Phase 0.52026-02-11
R-013No CSRF protection on state-changing API endpointsTechnical248MitigateJohnMitigating — CSRF middleware in Phase 0.52026-02-11
R-014Cash flow gap if Innovasjon Norge grant delayedFinancial339MitigateAlemMonitoring — AI costs keep burn < 10K/month2026-02-08
R-015Race condition on concurrent remittance transactions (double-spend)Technical2510MitigateJohnMitigating — per-user transaction lock implementation2026-02-11

6. Risk Response Strategies

If infees;
Risk ID Strategy Response Actions Contingency Plan Resources Required
R-001 {{STRATEGY}}Mitigate 1. {{ACTION_1}};SpareBank1 pitch submitted; 2. {{ACTION_2}}Swan evaluated as backup; 3. Modular BaaS interface in architecture {{CONTINGENCY_IF_RISK_OCCURS}} {{RESOURCES}}neither works: explore Wio Bank, Finom, Treezor
R-002 Mitigate 1. IdentifyEngage backupexternal decision-maker;legal advisor for Finanstilsynet process; 2. SetApply approvalearly; deadlines3. Operate under bank partner licence initiallyIf delayed: launch in contract;limited 3.beta Asyncunder approvalpartner processEscalate to John → client sponsorPM time: 2h/weeklicence
R-003 Mitigate + Accept 1. AbstractSecurity APIaudit calls behind service layer;complete; 2. MonitorPhase vendor0.5 changelog;sprint fixes 8 critical issues; 3. BuildNo integrationreal testsmoney in MVP SwitchIf tobreach alternativeoccurs: vendor;incident allocateresponse 3-dayplan buffer Tech Lead: 1 day setupsecurity/incident-response.md
R-004 Avoid + MitigateAccept 1.Monitor DetailedVipps BRDannouncements sign-offmonthly; beforeaccelerate development;community 2. Formal change request process enforced; 3. Weekly scope reviewadoption RaiseEmphasise change0.5% request;vs negotiateVipps timeline/budget BA:focus 2h/weekon scopetrust monitoring

Response Strategy Definitions

StrategyWhen to UseAction
AvoidHigh score + feasible to eliminateChange plan to remove the risk sourceadvantage
MitigateR-005 Cannot avoid; must reduce probability or impactMitigate Implement1. controls,Door-to-door monitoring,onboarding; early2. warning0% systemsfee for first 3 months; 3. 200-merchant target Month 12Adjust fee structure; focus on high-volume corridors
TransferR-006 Risk can be shared with third partyMitigate Insurance,1. contractualJWT_SECRET liabilityrequired transfer,env outsourcingvar — fail fast; 2. Secrets via VaultwardenRotate secrets immediately; force re-auth
Accept (Active)R-007 Low score; mitigation cost > risk costMitigate Monitor1. andRemove createCVV contingencyfrom planGET response; 2. Store only last_four + token_ref; 3. Tokenisation via card partnerSuspend cards feature until fixed
Accept (Passive)R-010 Negligible scoreMitigate Acknowledge,1. noSumsub actionintegration requiredcontract; 2. Mock clearly gated by feature flag; 3. No real money until KYC liveSuspend onboarding until KYC active
EscalateR-015 Exceeds project authority or appetiteMitigate Raise1. toPer-user Johntransaction /lock Alem(in-process); /2. clientDB-level sponsorconstraint as backup; 3. PostgreSQL advisory locks in Phase 2Suspend concurrent transactions; queue-based processing

7. Risk Heat Map

quadrantChart
    title Drop Risk Heat Map — {{PROJECT_NAME}}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:001 (BaaS partner): [1.0, 0.8]
    R-002 (Finanstilsynet): [1.0, 0.8]
    R-004 (Vipps): [0.7,8, 0.5]6]
    R-002: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.5]6]
    R-003:014 (Cash flow): [0.8,6, 0.3]6]
    R-004:008 (SQLite): [0.5,6, 0.7]
    R-005: [0.7, 0.5]4]

Update coordinates as Probability/Impact scores change. X = Impact/5, Y = Probability/5.

8. Escalation Thresholds

Threshold Action Responsible Timeframe
Any new risk Score ≥ 15 Immediate escalationEscalate to JohnAlem + AlemJohn PMJohn Within 4 hours of identification
Any existing risk score increases by ≥ 5 Escalate to John PMJohn Within 24 hours
> 3 risks at Score ≥ 10 simultaneously Emergency risk review meeting PMJohn + JohnAlem Within 48 hours
Any riskRisk triggers its contingency plan Notify all stakeholders PMJohn Immediately
Risk causes milestone slip > 3 days Formal change request + escalation PMJohn Within 24 hours

9. Risk Review Schedule

Frequency Activity Participants Output
Weekly (Sprint Planning) Review all active risks, update scores/statusscores PM, Tech LeadJohn Updated register
Sprint Retrospective Identify new risks; close resolvedNew risks identified; closed risks archived Full teamJohn New risks addedlogged
Monthly Full risk register review + heat map update PM,John, JohnAlem Risk report to stakeholders
Ad-hocNew risk identified (any time)Risk identifier + PMNew risk logged within 24h
Milestone Risk review before each major milestonego/no-go PM,John, Tech Lead, JohnAlem Go/no-go input

Review Log

Date Reviewer Risks Reviewed New Risks Added Risks Closed Key Changes
{{DATE}}2026-02-08 {{NAME}}legal + finance agents {{COUNT}}— {{COUNT}}6 {{COUNT}}0 {{SUMMARY}}Initial identification
2026-02-11John (security audit)6100Added R-006 through R-015
2026-02-23John1505Closed R-C01 to R-C05; updated statuses

10. Closed / Accepted Risks Archive

ID Risk Description Resolution Type Resolution Notes Date Closed
R-999C01 Example:Wallet/balance Third-partymodel paymentrequires providere-money delayslicenceAvoidedPivoted to PSD2 pass-through model (ADR-003)2026-02-12
R-C02FontelePay tightly coupled to Drop — regulatory riskAvoidedSeparated to own module (ADR-002)2026-02-12
R-C03Zica brand name has cultural sensitivityAvoidedRebranded to Drop (Alem decision 2026-02-09)2026-02-09
R-C04"Banking" language in UI creates regulatory exposure Mitigated SwitchedRemoved toall backup"banking" provider;references nofrom impactUI (task #197) {{DATE}}2026-02-09
R-C05SHA-256 password support creates rainbow table vulnerabilityMitigatedSHA-256 support removed; bcrypt-only policy enforced2026-02-13

Approval

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