Change Request Template: Drop — Fintech Payment App 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: flyctl deploy --app drop-app --image registry.fly.io/drop-app:{PREVIOUS_VERSION} (2–5 min) Verify health: curl https://drop-staging.fly.dev/api/health Run smoke tests: npx playwright test --project=user-flows If DB migrations ran: assess whether down migration is safe (Phase 0.5 migrations are all additive — generally safe to leave tables in place) 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