# 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:**
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 | |