Skip to main content

Change Request

Change Request Template: Drop — Fintech Payment App

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

Document History

Version Date Author Changes
0.1 2026-02-23 John Initial CR template — Drop fintech context

How to Use This Template

A Change Request (CR) is submitted whenever a stakeholder wants to modify any approved project artifact — scope, timeline, budget, requirements, or design.

EVERY change must go through this process, no matter how "small" it seems. In fintech, one "small" change (e.g., adding a column to the users table) can violate PCI-DSS compliance and trigger a P0 incident.

Copy this template to docs/CROSS-CUTTING/change-requests/CR-{XXX}-{short-title}.md and fill in all fields.

Drop-Specific Rules:

  • Any schema change to users or cards tables requires explicit compliance review — pass-through model (ADR-003) must not be violated
  • Any change to fee rates (currently 0.5% remittance, 1% QR) requires CEO sign-off from Alem Bašić
  • Any change affecting authentication, rate limiting, or JWT handling requires security review by John + Validator Agent
  • Changes that affect Finanstilsynet registration scope must be reviewed before submission

Change Request Log

CR ID Title Status Submitted Decision Date Impact
CR-001 Phase 0.5 Security Hardening Scope Approved 2026-02-23 2026-02-23 In-scope security fixes; no fee/schema changes
CR-002 (use template below)

[TEMPLATE STARTS HERE — Copy below for each new CR]

Change Request: {CR_TITLE}

1. Change Request Metadata

Field Value
CR ID CR-{XXX} (assigned by John as AI Director)
Date Submitted {DATE}
Submitted By {NAME} — {ROLE}
Project Drop — Remittance + QR Payments
Priority Critical / High / Medium / Low
CR Type Scope Change / Budget Change / Timeline Change / Requirements Change / Design Change / Technical Change
Current Phase Phase 0.5 Security Hardening / Phase 1 BaaS Integration / Phase 2 Compliance
Decision Deadline {DATE} (by when a decision must be made to avoid impact)

2. Change Description

2.1 Summary of Change

{ONE_PARAGRAPH_SUMMARY_OF_WHAT_CHANGES}

2.2 Current State (Before)

{DESCRIPTION_OF_CURRENT_STATE}

Currently approved in: {DOCUMENT_NAME_AND_VERSION}, Section {X.X}

Drop compliance check — Current state:

  • Does the current state involve the users.balance column? Yes / No — (Must remain: No)
  • Does the current state involve cards.card_number or cards.cvv? Yes / No — (Must remain: No)
  • Does the current state involve fee rates? Yes / No — (Current: remittance 0.5%, QR 1%)

2.3 Proposed State (After)

{DESCRIPTION_OF_PROPOSED_STATE}

Drop compliance check — Proposed state:

  • Will the proposed state add a balance column to users? Yes / No — (If Yes: BLOCKED — violates ADR-003)
  • Will the proposed state store card_number or cvv in full? Yes / No — (If Yes: BLOCKED — violates PCI-DSS)
  • Does this change fee rates? Yes / No — (If Yes: CEO sign-off required)

2.4 Out of Scope for This Change

This CR does NOT include:

  • {EXPLICITLY_EXCLUDED_ITEM_1}
  • {EXPLICITLY_EXCLUDED_ITEM_2}

3. Reason & Justification

3.1 Reason for Change

Reason Category Applies? Details
New business requirement discovered Yes / No {DETAILS}
Regulatory / compliance mandate Yes / No {DETAILS}
Client feedback from UAT / prototype Yes / No {DETAILS}
Technical blocker / infeasibility Yes / No {DETAILS}
Market opportunity / competitive pressure Yes / No {DETAILS}
Error/omission in original requirements Yes / No {DETAILS}
Performance / quality improvement Yes / No {DETAILS}
Security finding from audit Yes / No Reference: security/drop-security-rapport.md SEC-{ID}

Primary Justification: {CLEAR_BUSINESS_JUSTIFICATION_WHY_THIS_CHANGE_IS_NECESSARY}

3.2 Consequence of Not Changing

If this change is not approved: {CONSEQUENCE_OF_REJECTION}

4. Impact Analysis

4.1 Scope Impact

Deliverable Affected Current Scope Proposed Scope Impact Type
{DELIVERABLE} {CURRENT} {PROPOSED} Added / Removed / Modified

Scope Change Size: Small (< 1 day) / Medium (1–3 days) / Large (3–10 days) / Major (> 10 days)

4.2 Timeline Impact

Milestone Current Date New Date (if approved) Delay
Phase 0.5 Security Hardening 2026-02-28 {NEW_DATE} {DAYS} days
Phase 1 BaaS Integration 2026-04-30 {NEW_DATE} {DAYS} days
Finanstilsynet Registration 2026-05-31 {NEW_DATE} {DAYS} days

Timeline Impact: None / Minor (≤ 3 days) / Moderate (4–14 days) / Major (> 14 days) Critical Path Impact: Yes / No If yes: {WHICH_CRITICAL_PATH_ITEMS_AFFECTED}

4.3 Budget Impact

Cost Category Current Budget (NOK) Additional Cost (NOK) Notes
Development 150,000 (Innovasjon Norge + bootstrap) {ADDITIONAL} {NOTES}
Design — {ADDITIONAL}
Testing — {ADDITIONAL}
Infrastructure (Fly.io) — {ADDITIONAL}
Total Additional Cost {TOTAL_ADDITIONAL}

Budget Impact: None / Minor (< 5%) / Moderate (5–15%) / Major (> 15%) Total Drop budget: ~250,000 NOK (150K Innovasjon Norge + bootstrap) Funding Source for Additional Cost: {HOW_WILL_ADDITIONAL_COST_BE_COVERED}

4.4 Resource Impact

Resource Current Allocation Required if Approved Impact
Builder Agent (Claude Sonnet) Per-task {NEW_ALLOCATION} {NOTES}
Validator Agent (Claude Sonnet) Per-review {NEW_ALLOCATION}
John (AI Director) Architecture + coordination {NEW_ALLOCATION}

4.5 Risk Impact

Risk Probability Impact Notes
{NEW_RISK_INTRODUCED} H/M/L H/M/L
Pass-through model violation risk L (if schema touched) Critical Always assess for schema changes

4.6 Quality Impact

  • Test cases affected: {LIST_OF_TEST_CASES_NEEDING_UPDATE}
  • Regression risk: {HIGH/MEDIUM/LOW} — {EXPLANATION}
  • NFRs affected: {LIST_ANY_NFRs_IMPACTED}
  • db.test.ts pass-through assertions: Will these still pass? Yes / Needs update — {EXPLANATION}
  • api-endpoints.test.ts: Will existing 26 API endpoint tests still pass? Yes / Needs update

4.7 Affected Deliverables / Documents

Document Section Type of Change Owner
docs/backend/API-REFERENCE.md {SECTION} Update / Add / Remove John
docs/backend/DATABASE-SCHEMA.md {SECTION} Update / Add / Remove John
CLAUDE.md {SECTION} Update John
docs/BUSINESS-REQUIREMENTS/functional-requirements.md FR-{XXX} Modify John
Test cases TC-{XXX} Update Builder Agent + Validator Agent

5. Alternative Approaches Considered

Alternative Description Why Rejected
Option A (Proposed) {THIS_CR} Recommended
Option B {ALTERNATIVE} {WHY_NOT_CHOSEN}
Option C — Do Nothing Reject the change {CONSEQUENCE_OF_REJECTION}

Recommendation: Option {A/B/C} Rationale: {WHY_THIS_IS_THE_BEST_OPTION}

6. Implementation Plan

6.1 Implementation Steps

# Task Owner Effort Target Date
1 {TASK} Builder Agent {EFFORT} {DATE}
2 Update db.test.ts if schema changes Builder Agent S {DATE}
3 Update test cases for affected features Builder Agent + Validator Agent {EFFORT} {DATE}
4 Update requirements and API reference docs John {EFFORT} {DATE}
5 Regression testing (npm run test + npx playwright test) Validator Agent M {DATE}
6 Deploy to staging (https://drop-staging.fly.dev/) and verify Builder Agent S {DATE}

6.2 Dependencies

Dependency Type Blocking?
{DEPENDENCY} Internal / External Yes / No
Fly.io staging environment Infrastructure No (always available)
BaaS partner confirmation (for Phase 2 changes) External Yes (for live money movement)

6.3 Test Plan for This Change

  • Unit tests: {WHICH_UNITS_NEED_NEW/UPDATED_TESTS} — add to relevant __tests__/*.test.ts
  • Integration tests: {WHAT_INTEGRATIONS_TO_RETEST} — api-endpoints.test.ts
  • DB compliance: db.test.ts must still pass (no balance, no CVV)
  • Regression scope: Full npm run test (40+ tests) + npx playwright test (3 projects)
  • UAT: {DOES_THIS_REQUIRE_CEO_UAT? Y/N — WHICH_SCENARIOS}

7. Rollback Plan

Rollback Trigger: {WHAT_CONDITION_TRIGGERS_ROLLBACK} (e.g., error rate > 1% post-deploy, smoke tests failing, pass-through model violation detected)

Rollback Steps:

  1. flyctl deploy --app drop-app --image registry.fly.io/drop-app:{PREVIOUS_VERSION} (2–5 min)
  2. Verify health: curl https://drop-staging.fly.dev/api/health
  3. Run smoke tests: npx playwright test --project=user-flows
  4. If DB migrations ran: assess whether down migration is safe (Phase 0.5 migrations are all additive — generally safe to leave tables in place)
  5. Update Mission Control incident task with rollback details

Rollback Owner: John (AI Director) Rollback Time Required: 5–10 minutes Data Recovery Needed: No (mock BaaS — no real transactions in Phase 0.5)

8. Approval Workflow

8.1 Approval Matrix — Drop

Impact Type Required Approvals Target Decision Time
No budget/timeline impact John (AI Director) 1 business day
Schema change (any) John + Validator Agent compliance check 1 business day
Fee rate change John + Alem Bašić (CEO) 2 business days
Budget impact < 5% OR timeline < 3 days John + Alem Bašić 2 business days
Budget impact 5–15% OR timeline 3–14 days John + Alem Bašić (CEO) 3 business days
Budget impact > 15% OR timeline > 14 days John + Alem Bašić (CEO) + Board 5 business days
Finanstilsynet registration scope change John + Alem Bašić + Legal review 5 business days

8.2 This Change Requires

  • Tech Lead Review — Technical feasibility and effort confirmed (John)
  • Validator Agent Review — DB compliance check: no balance/CVV violation
  • John (AI Director) — Architecture accountability + Mission Control task created
  • Alem Bašić (CEO) — Fee rate changes, budget > 5%, or scope changes affecting BaaS/Finanstilsynet

8.3 Decision Record

Level Reviewer Decision Date Comments
Tech Lead John Approved / Rejected / Deferred {DATE} {COMMENTS}
Validator Agent Validator Approved / Rejected {DATE} DB compliance: pass-through model intact?
AI Director John Approved / Rejected {DATE}
CEO (Alem) Alem Bašić Approved / Rejected {DATE} (required for fee/budget/scope changes)

Final Decision: APPROVED / REJECTED / DEFERRED Decision Date: {DATE} Effective From Sprint: Phase {X.X} / Sprint {X}

9. Change Log

Date Changed By What Changed
{DATE} {NAME} {WHAT_CHANGED}

Approval

Role Name Date Signature
Author John (AI Director) 2026-02-23 Approved (AI)
Tech Lead John 2026-02-23 Approved
CEO (Alem) Alem Bašić TBD
Back to top