Skip to main content

Functional Requirements

Functional Requirements Specification (FRS): {{PROJECT_NAME}}Drop — Fintech Payment App

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

Document History

Version Date Author Changes
0.1 {{DATE}}2026-02-23 {{AUTHOR}}John Initial draft based on CLAUDE.md, API-REFERENCE.md, DATABASE-SCHEMA.md

1. System Overview

System Name: {{SYSTEM_NAME}}Drop — Fintech Payment App System Purpose: {{PURPOSE_2_3_SENTENCES}}Drop is a PSD2 pass-through payment app for residents of Norway/Scandinavia. It enables international remittance (PISP bank transfer at 0.5% fee) and QR-code merchant payments (PISP at 1% fee) directly from users' Norwegian bank accounts — without holding any customer funds. Users are onboarded via Norwegian BankID (18+ required).

System Context Diagram:

graph TB
    subgraph "{{SYSTEM_NAME}}"Drop Application"
        UI[Next.js Web /App Mobile- UI]10 screens]
        API[BackendNext.js API]API Routes - 26 endpoints]
        DB[(Database)SQLite → PostgreSQL)]
    end
    U1[{{USER_TYPE_1}}]Consumer User] -->|Uses|BankID login| UI
    U2[{{USER_TYPE_2}}]Merchant User] -->|Uses|QR management| UI
    API -->|Reads/Writes| DB
    API -->|Integrates|PISP EXT1[{{EXTERNAL_SERVICE_1}}]payment initiation| BAAS[BaaS Provider - Swan/SpareBank1]
    API -->|Integrates|AISP EXT2[{{EXTERNAL_SERVICE_2}}]balance ADM[Admin]read| BAAS
    API -->|Manages|KYC UIverification| KYC[KYC Provider - Sumsub]
    BAAS -->|Open Banking| BANKS[Norwegian Banks - PSD2]
    BAAS -->|SCA| BANKID[BankID]
    API -->|Remittance corridors| CORRIDOR[30+ countries]

2. Actors & Personas

Actor ID Actor Name Type Description Access Level
ACT-01 {{ACTOR_NAME}}Human / System{{DESCRIPTION}}{{ROLE/PERMISSIONS}}
ACT-02EndConsumer User Human {{PERSONA_DESCRIPTION}}Norwegian resident (18+) sending money abroad or paying merchants Authenticated user
ACT-0302 AdministratorMerchant User Human ManagesLocal systembusiness configurationowner andaccepting usersQR payments AdminAuthenticated merchant
ACT-03BaaS ProviderSystemSwan or SpareBank1 — Open Banking API (AISP/PISP)System integration
ACT-04 {{EXTERNAL_SYSTEM}}KYC Provider System ExternalSumsub service— integratedidentity viaverification APIand AML screening System integration
ACT-05BankIDSystemNorwegian strong customer authentication (SCA)System integration

Persona Detail

Persona: {{PERSONA_NAME}}Amir (Consumer)

  • Role: {{JOB_TITLE}}Software developer, immigrant from Bosnia
  • Goal: {{PRIMARY_GOAL_USING_SYSTEM}}Send 3,000 NOK/month to his mother in Sarajevo cheaply and reliably; also pay at Ahmet's kebab shop
  • Pain Points: {{CURRENT_FRUSTRATIONS}}Western Union charges 10%; needs 2 separate apps for remittance and local payments
  • Tech Savviness: Low / Medium / High
  • Frequency of Use: Weekly (remittance monthly; QR payments weekly)

Persona: Ahmet (Merchant)

  • Role: Owner of kebab shop in Oslo
  • Goal: Accept payments without Vipps terminal; lower fees; understand daily revenue
  • Pain Points: Vipps charges 1.75-2.75%; requires hardware terminal; fees eat into margins
  • Tech Savviness: Medium
  • Frequency of Use: Daily /(receives Weekly20-50 /QR Monthlypayments/day)

3. Functional Requirements

3.1 Module: {{MODULE_1_NAME}}Authentication & BankID Onboarding

Module Overview

{{MODULE_DESCRIPTION}}User registration and login via Norwegian BankID SCA. Age (18+) and residency (Norway, +47 phone) verified. JWT tokens issued in httpOnly cookies. 3-step onboarding: BankID verification → OTP verification → PIN setup.

FR-001: {{FEATURE_NAME}}User Registration (3-step onboarding)

Attribute Value
Module {{MODULE_1_NAME}}Authentication
Priority Must Have
Trace BR-{{XXX}}001, BR-002
UI Reference [Figma link or mockup filename]mockups/figma-make-export/src/components/Onboarding.js

Description: {{FEATURE_DESCRIPTION_IN_BUSINESS_LANGUAGE}}

New

Acceptanceusers Criteria:

register
    via
  • a Given3-step {{PRECONDITION}},flow: when(1) {{USER_ACTION}},personal thendetails {{EXPECTED_RESULT}}
    • +
  • BankID, Given(2) {{PRECONDITION}},OTP whenverification {{USER_ACTION}},via thenNorwegian {{EXPECTED_RESULT}}
    • phone
  • number, Given(3) invalidPIN input, when {{USER_ACTION}}, then {{ERROR_HANDLING}}

Data Requirements:

  • Input: {{INPUT_DATA_FIELDS_AND_TYPES}}
  • Output: {{OUTPUT_DATA}}
  • Validation: {{VALIDATION_RULES}}

Business Rules:

  • RUL-{{XX}}: {{APPLICABLE_BUSINESS_RULE}}

Dependencies: FR-{{XXX}}, DEP-{{XX}}

FR-002: {{FEATURE_NAME}}

AttributeValue
Module{{MODULE_1_NAME}}
PriorityMust Have
TraceBR-{{XXX}}
UI Reference

Description: {{FEATURE_DESCRIPTION}}

Acceptance Criteria:

  •  Given {{PRECONDITION}}, when {{USER_ACTION}}, then {{EXPECTED_RESULT}}
  •  Given {{PRECONDITION}}, when {{USER_ACTION}}, then {{EXPECTED_RESULT}}

Data Requirements:

  • Input: {{INPUT}}
  • Output: {{OUTPUT}}
  • Validation: {{VALIDATION}}

Business Rules: {{APPLICABLE_RULES}}

Dependencies: {{DEPENDENCIES}}

3.2 Module: {{MODULE_2_NAME}}

Module Overview

{{MODULE_DESCRIPTION}}

FR-010: {{FEATURE_NAME}}

AttributeValue
Module{{MODULE_2_NAME}}
PriorityMust Have
TraceBR-{{XXX}}
UI Reference

Description: {{FEATURE_DESCRIPTION}}

Acceptance Criteria:

  •  Given {{PRECONDITION}}, when {{USER_ACTION}}, then {{EXPECTED_RESULT}}
  •  Given {{PRECONDITION}}, when {{USER_ACTION}}, then {{EXPECTED_RESULT}}

Data Requirements:

  • Input: {{INPUT}}
  • Output: {{OUTPUT}}
  • Validation: {{VALIDATION}}

Business Rules: {{APPLICABLE_RULES}}

Dependencies: {{DEPENDENCIES}}

3.3 Module: Authentication & Authorization

FR-020: User Registration

AttributeValue
PriorityMust Have
TraceBR-{{XXX}}

Description:setup. Users canmust createbe a≥18 newyears accountold using(validated emailvia andBankID password.DOB). Norwegian phone (+47) required.

Acceptance Criteria:

  • Given a valid email andemail, password (≥8 chars,chars), 1Norwegian uppercase,phone 1(+47), number),and DOB ≥18 years, when user submits registration form,registration, then account is created and confirmationuser emailproceeds isto sentOTP step
  •  Given a user under 18 years old, when they submit registration, then system rejects with "Du må være minst 18 år"
  • Given an already-registered email, when user tries to register, then system showsreturns 409 "Email already in use" error
  • Given passwordOTP doesis notsent, meetwhen complexityuser rules,enters correct 6-digit code, then user proceeds to PIN setup
  •  Given PIN setup, when user enters and confirms 4-digit PIN, then account is activated
  •  Given invalid email format, when user submits, then inline422 validation error shownwith beforespecific submitfield details

Data Requirements:

  • Input: email (unique), password,password {{ADDITIONAL_FIELDS}}(≥8 chars), first_name, last_name, phone (+47), date_of_birth
  • Output: user record,record confirmation(id, kyc_status=pending), JWT token in httpOnly cookie
  • Validation: email format,format (regex), password complexity,length, duplicatephone checkformat, DOB ≥18

Business Rules: RUL-001, RUL-002, RUL-008

Dependencies: None

FR-021:002: User Login

Attribute Value
ModuleAuthentication
Priority Must Have
Trace BR-{{XXX}}001
UI Referencemockups/figma-make-export/src/components/Login.js

Description: Authenticated users canUsers log in with email and+ password. JWT token issued in httpOnly cookie (7-day expiry). Failed logins rate-limited.

Acceptance Criteria:

  • Given valid credentials,email + password, when user submits login form,login, then userJWT iscookie authenticatedset and user redirected to dashboard
  • Given invalid credentials, when user submits, then generic error401 "Invalid email or password" is shown (no user enumeration)
  • Given 510+ consecutiveattempts failedfrom attempts,same IP in 1 minute, when user tries again, then account429 israte temporarilylimit locked for 15 minutesresponse
  • Given an authenticated session,session idle for 7 days, when user ismakes idle for 30 minutes,request, then sessiontoken expiresexpired; and user is redirectedredirect to login

Data Requirements:

  • Input: email, password
  • Output: JWT in httpOnly cookie (SameSite=Strict); user object (id, email, role, kyc_status)
  • Validation: email format, password non-empty

Business Rules: RUL-001, RUL-002

Dependencies: FR-001

FR-003: Session Management + Logout

AttributeValue
ModuleAuthentication
PriorityMust Have
TraceBR-001

Description: Authenticated routes require valid JWT. Logout clears the cookie and revokes the session in the database. GET /api/auth/me returns current user.

Acceptance Criteria:

  •  Given authenticated user, when they call GET /api/auth/me, then current user object returned
  •  Given unauthenticated user, when they access protected route, then 401 Unauthorized
  •  Given authenticated user, when they POST /api/auth/logout, then cookie cleared and session revoked in DB

Business Rules: RUL-001

Dependencies: FR-002

3.2 Module: KYC Verification

Module Overview

Know-Your-Customer identity verification required before any transaction. In MVP: Sumsub integration (mocked in demo). Users with kyc_status=approved can transact; others are blocked with clear messaging.

FR-010: KYC Identity Verification

AttributeValue
ModuleKYC
PriorityMust Have
TraceBR-001, BR-002

Description: Users must complete KYC verification before initiating their first transaction. KYC status stored per user: pending → in_review → approved | rejected. In production: Sumsub document + biometric verification.

Acceptance Criteria:

  •  Given user with kyc_status=pending, when they attempt remittance, then 403 "KYC verification required" with link to complete
  •  Given approved user, when they initiate transaction, then transaction proceeds
  •  Given Sumsub webhook callback with approved status, when received, then user kyc_status updated to approved
  •  Given rejected user, when they attempt transaction, then 403 with rejection reason

Business Rules: RUL-008

Dependencies: FR-001

3.3 Module: Remittance (Send Money)

Module Overview

Core revenue stream #1. Users send money to 30+ countries at 0.5% fee via PISP. The payment is initiated directly from the user's Norwegian bank account. Recipient receives bank transfer or cash pickup within 1-2 business days.

FR-020: Send Money — Remittance Flow

AttributeValue
ModuleRemittance
PriorityMust Have
TraceBR-003, BR-005
UI Referencemockups/figma-make-export/src/components/SendMoney.js

Description: Authenticated, KYC-approved users can send money to recipients in 30+ countries. Fee: 0.5% of transaction amount. Supported MVP corridors: NOK→RSD, NOK→BAM, NOK→PKR, NOK→TRY, NOK→PLN, NOK→EUR.

Acceptance Criteria:

  •  Given authenticated + KYC-approved user and valid recipient, when POST /api/transactions/remittance with amount 100-50,000 NOK, then 201 transaction created; fee calculated as amount × 0.005
  •  Given unauthenticated user, when they attempt remittance, then 401 Unauthorized
  •  Given user with insufficient balance, when they attempt remittance, then 402 "Insufficient balance"
  •  Given amount below 100 NOK or above 50,000 NOK, when user submits, then 400 validation error
  •  Given valid transaction, when completed, then transaction_history record created with status=completed, correct fee

Data Requirements:

  • Input: recipientId, amount (100-50,000 NOK), currency (RSD/BAM/PKR/TRY/PLN/EUR), note (optional)
  • Output: transaction_id, amount, fee (amount × 0.005), recipient_amount, status, created_at
  • Validation: amount range, recipientId exists, KYC approved, balance sufficient

Business Rules: RUL-003, RUL-005, RUL-007, RUL-008

Dependencies: FR-002, FR-010, FR-040 (recipients)

FR-021: Exchange Rates

AttributeValue
ModuleRemittance
PriorityMust Have
TraceBR-003

Description: Current NOK exchange rates for all supported corridors. GET /api/rates returns all; GET /api/rates/[currency] returns specific rate.

Acceptance Criteria:

  •  Given GET /api/rates, when called, then returns all 6 NOK exchange rates (RSD, BAM, PKR, TRY, PLN, EUR)
  •  Given GET /api/rates/RSD, when called, then returns NOK→RSD rate
  •  Given GET /api/rates/XXX (invalid), when called, then 404 Not Found
  •  Given rate query, when currency code is lowercase, then case-insensitive match

Dependencies: None

FR-022: Recipients Management

AttributeValue
ModuleRemittance
PriorityMust Have
TraceBR-003

Description: Users can add, list, and reuse recipients for remittance. Recipients have name, country, bank account / IBAN.

Acceptance Criteria:

  •  Given authenticated user, when POST /api/recipients with valid data, then recipient created and associated with user
  •  Given authenticated user, when GET /api/recipients, then all user's recipients returned
  •  Given IBAN provided, when validated, then reject invalid IBAN format
  •  Given unauthenticated user, when accessing recipients, then 401 Unauthorized

Business Rules: RUL-003

Dependencies: FR-002

3.4 Module: {{MODULE_N_NAME}}QR Payments (Merchant + Consumer)

Module Overview

Core revenue stream #2. Merchants generate QR codes via Drop; consumers scan and pay. 1% merchant fee. Settlement via daily batch payout to merchant bank account.

FR-030: {{FEATURE_NAME}}QR Payment — Consumer Flow

AttributeValue
ModuleQR Payments
PriorityMust Have
TraceBR-004, BR-005
UI Referencemockups/figma-make-export/src/components/ScanQR.js

Description: Consumer scans merchant's QR code → enters amount → confirms → payment initiated via PISP from bank account. Fee: 1% charged to merchant. Consumer sees confirmation; merchant receives push notification.

Acceptance Criteria:

  •  Given authenticated + KYC-approved user, when POST /api/transactions/qr-payment with valid merchantId and amount ≥1 NOK, then 201 transaction created; merchant fee calculated as amount × 0.01
  •  Given invalid merchantId, when user pays, then 404 "Merchant not found"
  •  Given amount < 1 NOK, when submitted, then 400 validation error
  •  Given missing merchantId, when submitted, then 400 validation error
  •  Given successful payment, when completed, then both user and merchant transaction records updated

Data Requirements:

  • Input: merchantId, amount (≥1 NOK), note (optional)
  • Output: transaction_id, amount, merchant_fee (amount × 0.01), status, merchant details
  • Validation: merchantId exists, amount ≥1, KYC approved, balance sufficient

Business Rules: RUL-003, RUL-006, RUL-008

Dependencies: FR-002, FR-010, FR-031

FR-031: Merchant Registration + QR Generation

AttributeValue
ModuleQR Payments
PriorityMust Have
TraceBR-004, BR-006
UI Referencemockups/figma-make-export/src/components/MerchantDashboard.js

Description: Merchants register their business (name, address, bank account) and receive a unique QR code. Self-service onboarding < 5 minutes.

Acceptance Criteria:

  •  Given authenticated user, when POST /api/merchants with valid business data, then merchant record created with unique QR code value
  •  Given merchant, when GET /api/merchants/me, then merchant details + QR code returned
  •  Given QR code, when scanned by Drop consumer app, then merchant identified and payment flow initiated

Business Rules: RUL-006

Dependencies: FR-002, FR-010

FR-032: Merchant Dashboard Analytics

AttributeValue
ModuleQR Payments
PriorityShould Have
TraceBR-011

Description: Merchants view transaction volume, revenue, and fees by time period (today/week/month).

Acceptance Criteria:

  •  Given authenticated merchant, when GET /api/merchants/dashboard?period=week, then total transactions, gross volume, fees earned returned
  •  Given invalid period, when queried, then defaults to today

Dependencies: FR-031

3.5 Module: Bank Accounts (AISP)

Module Overview

Read-only view of user's linked bank account balance via AISP (Open Banking). Drop never holds funds — balance displayed for user awareness only.

FR-040: Bank Account Balance View

AttributeValue
ModuleBank Accounts
PriorityShould Have
TraceBR-010
UI Referencemockups/figma-make-export/src/components/BankAccounts.js

Description: Users view their linked bank account balance from their Norwegian bank via AISP. In MVP: mock balance from demo account. In Phase 2: real Open Banking AISP via BaaS provider.

Acceptance Criteria:

  •  Given authenticated user, when GET /api/bank-accounts, then linked bank account(s) with masked account number and balance returned
  •  Given user with no linked account, when viewing accounts, then prompt to link bank via BankID

Business Rules: RUL-003

Dependencies: FR-002, FR-010

3.6 Module: Transaction History

Module Overview

Users view all their transactions (remittance, QR payments) with filters by type, date, status.

FR-050: Transaction History

AttributeValue
ModuleTransaction History
PriorityShould Have
TraceBR-009
UI Referencemockups/figma-make-export/src/components/TransactionHistory.js

Description: Authenticated users view all transactions with pagination. Filterable by type (remittance/qr_payment) and date range.

Acceptance Criteria:

  •  Given authenticated user, when GET /api/transactions, then all user's transactions returned (most recent first)
  •  Given query params, when ?type=remittance, then filtered results returned
  •  Given unauthenticated user, when accessing transactions, then 401 Unauthorized

Dependencies: FR-002

3.7 Module: Notifications

Module Overview

Push notifications for transaction events. Users receive alerts for incoming/outgoing transactions.

FR-060: Transaction Notifications

AttributeValue
ModuleNotifications
PriorityShould Have
TraceBR-008
UI Referencemockups/figma-make-export/src/components/Notifications.js

Description: Users receive push notifications when transactions are created or completed. Notifications stored in DB and viewable in-app.

Acceptance Criteria:

  •  Given authenticated user, when GET /api/notifications, then all user's notifications returned (unread first)
  •  Given new transaction, when completed, then notification record created for relevant user(s)
  •  Given user marks notification as read, when PATCH /api/notifications/[id], then status updated

Dependencies: FR-020, FR-030

3.8 Module: User Profile & Settings

Module Overview

Users view and update their profile information, manage app preferences.

FR-070: User Profile

AttributeValue
ModuleProfile
PriorityShould Have
TraceBR-007
UI Referencemockups/figma-make-export/src/components/Profile.js

Description: Authenticated users view their profile details, update preferences, and initiate account deletion (GDPR right to erasure).

Acceptance Criteria:

  •  Given authenticated user, when GET /api/auth/me, then user profile returned (no password hash)
  •  Given authenticated user, when DELETE /api/user/account, then account deletion initiated per GDPR

Business Rules: RUL-007 (GDPR right to deletion)

Dependencies: FR-002

3.9 Module: Feature Flags

Module Overview

Feature flag system controls access to beta/future features without code deployment.

FR-080: Feature Flag Control

AttributeValue
ModuleFeature Flags
PriorityShould Have
TraceBR-014

Description: 8 feature flags control access to Cards (feature-flagged), Top-up (removed), and other future features. Controlled via environment variables.

Acceptance Criteria:

  •  Given FF_CARDS_ENABLED=false, when user accesses /cards, then 404-equivalent feature gate response
  •  Given FF_CARDS_ENABLED=true, when user accesses /cards, then full cards feature accessible
  •  Given GET /api/feature-flags, when called, then all 8 flags with current values returned

Business Rules: Cards feature requires card partner agreement (RUL-010)

Dependencies: None

4. Use Case Diagrams

4.1 {{MODULE_1_NAME}}Consumer User Use Cases

graph LR
    A1(({{ACTOR_1}})Consumer)) --> UC1[FR-001: {{FEATURE}}]Register via BankID]
    A1 --> UC2[FR-002: {{FEATURE}}]Login]
    A2(({{ACTOR_2}}))A1 --> UC3[FR-010:020: {{FEATURE}}]Send Money Remittance]
    A1 --> UC4[FR-030: Pay via QR Scan]
    A1 --> UC5[FR-040: View Bank Balance]
    A1 --> UC6[FR-050: View Transaction History]
    A1 --> UC7[FR-060: View Notifications]

4.2 Merchant User Use Cases

graph LR
    A2((Merchant)) --> UC1[FR-001: Register]
    A2 --> UC2[FR-031: Register Business + Get QR]
    A2 --> UC3[FR-032: View Dashboard Analytics]
    A2 --> UC4[FR-011:060: {{FEATURE}}]Receive A3((Admin))Payment --> UC5[FR-020: {{FEATURE}}]
    A3 --> UC6[FR-021: {{FEATURE}}]

4.2 System-Level Use Case Overview

graph LR
    subgraph "{{SYSTEM_NAME}}"
        UC1[{{MODULE_1}} Functions]
        UC2[{{MODULE_2}} Functions]
        UC3[Auth Functions]
    end
    ACT1(({{ACTOR_1}})) --> UC1
    ACT1 --> UC3
    ACT2(({{ACTOR_2}})) --> UC2
    ACT2 --> UC3
    ACT3((Admin)) --> UC1
    ACT3 --> UC2
    ACT3 --> UC3Notifications]

5. System Behavior Specifications

5.1 Error Handling

  • All user-facing errors mustreturn display{error, amessage, human-readabledetails?} messageJSON (no stack traces)
  • All errors must be logged with correlation ID, timestamp, user ID (if authenticated), and actionformat
  • Validation errors: 422 with details array listing per-field errors shown inline, adjacent to the invalid field
  • SystemAuthentication errorserrors: show401 generic(never messagereveal +if contactemail info;exists)
    • full
  • Rate detaillimit loggederrors: server-side429 onlywith Retry-After header
  • No stack traces in production responses

5.2 Data Persistence

  • All user-submittedmutations datalogged mustwith beuser_id, persistedip, within {{X}} secondstimestamp
  • OptimisticTransaction UIrecords updatesare mustimmutable beonce rolledcreated back(status-only if server confirmation failsupdates)
  • AllACID mutationscompliance (create/update/delete)required mustfor befinancial audited with user ID and timestamptransactions

5.3 Session & State

  • SessionJWT timeout:expiry: {{X}}7 minutes of inactivitydays
  • ConcurrenthttpOnly sessioncookies behavior:(SameSite=Strict) {{ALLOW/BLOCK/NOTIFY}}prevent XSS token theft
  • BrowserCSRF refresh:protection applicationon stateall muststate-changing beendpoints restored from server(POST/PATCH/DELETE)

5.4 Notifications

  • EmailIn-app: notifications:all {{WHICH_EVENTS_TRIGGER_EMAILS}}transaction events (create, complete, fail)
  • In-appPush: notifications:Phase {{WHICH_EVENTS_TRIGGER_IN_APP}}2 (requires native mobile app)
  • PushEmail: notifications:account {{IF_APPLICABLE}}
    • registration,
  • Unsubscribesecurity mechanism required for all marketing emails (GDPR)alerts

5.5 AccessibilitySecurity Headers (Required)

  • WCAGHSTS, 2.1CSP, LevelX-Frame-Options: AADENY, complianceX-Content-Type-Options: requirednosniff
  • KeyboardReferrer-Policy: navigation for all interactive elements
  • Screen reader compatibility (ARIA labels)
  • Color contrast ratio ≥ 4.5:1strict-origin-when-cross-origin

6. Requirements Summary Table

ID Feature Name Module Priority Status Trace
FR-001 {{FEATURE}}{{MODULE}}Must HaveDraftBR-001
FR-002
FR-010
FR-020User Registration (3-step onboarding) Auth Must Have DraftImplemented BR-xxx001, BR-002
FR-021002 User Login Auth Must Have DraftImplemented BR-xxx001
FR-003Session Management + LogoutAuthMust HaveImplementedBR-001
FR-010KYC Identity VerificationKYCMust HaveMock (prod pending)BR-001
FR-020Send Money — RemittanceRemittanceMust HaveImplementedBR-003, BR-005
FR-021Exchange Rates APIRemittanceMust HaveImplementedBR-003
FR-022Recipients ManagementRemittanceMust HaveImplementedBR-003
FR-030QR Payment — ConsumerQR PaymentsMust HaveImplementedBR-004, BR-005
FR-031Merchant Registration + QRQR PaymentsMust HaveImplementedBR-004, BR-006
FR-032Merchant Dashboard AnalyticsQR PaymentsShould HaveImplementedBR-011
FR-040Bank Account Balance (AISP)Bank AccountsShould HaveMock (AISP pending)BR-010
FR-050Transaction HistoryHistoryShould HaveImplementedBR-009
FR-060Transaction NotificationsNotificationsShould HaveImplementedBR-008
FR-070User Profile + GDPR deletionProfileShould HaveImplementedBR-007
FR-080Feature Flag ControlFeature FlagsShould HaveImplementedBR-014

Requirements Count:

  • Must Have: {{COUNT}}7
  • Should Have: {{COUNT}}8
  • Could Have: {{COUNT}}0
  • Won't Have (this release): {{COUNT}}Cards virtual/physical (BR-014), Loyalty rewards (BR-012)

7. Traceability to Business Requirements

FR ID Feature Name Business Requirement (BR ID) Business Objective (BO ID)
FR-001 {{FEATURE}}User Registration BR-{{XXX}}001, BR-002 BO-{{XX}}02, BO-05
FR-002 User Login BR-001 BO-02
FR-010KYC VerificationBR-001, BR-007BO-05
FR-020RemittanceBR-003, BR-005BO-01, BO-02
FR-030QR PaymentsBR-004, BR-005BO-01, BO-03
FR-031Merchant RegistrationBR-004, BR-006BO-03
FR-040Bank Balance (AISP)BR-010BO-02

Full traceability matrix: [requirements-traceability-matrix.md](requirements-traceability-matrix.md)

Approval

Approved
Role Name Date Signature
Author John (AI Director) 2026-02-23
Reviewer
Business Analyst(AI)
Tech Lead John 2026-02-23 Approved
Product Owner John 2026-02-23 Approved
AI Director (John) John 2026-02-23 Approved
ClientCEO Representative(Alem) Alem Bašić TBD
Back to top