Non-Functional Requirements (NFR): Drop — Fintech Payment App
Non-Functional Requirements Specification (FRS)NFR): Drop — Fintech Payment App
Project: Drop — Remittance + QR Payments Version: 1.0 Date: 2026-02-23 Author: John (AI Director) Status: Approved Reviewers: Alem Bašić (CEO)
Document History
| Version | Date | Author | Changes |
|---|---|---|---|
| 0.1 | 2026-02-23 | John | Initial |
1. SystemNFR Overview
System Name: Drop — Fintech Payment App
System Purpose: 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 "Drop Application"
UI[Next.js Web App - 10 screens]
API[Next.js API Routes - 26 endpoints]
DB[(SQLite → PostgreSQL)]
end
U1[Consumer User] -->|BankID login| UI
U2[Merchant User] -->|QR management| UI
API -->|Reads/Writes| DB
API -->|PISP payment initiation| BAAS[BaaS Provider - Swan/SpareBank1]
API -->|AISP balance read| BAAS
API -->|KYC verification| KYC[KYC Provider - Sumsub]
BAAS -->|Open Banking| BANKS[Norwegian Banks - PSD2]
BAAS -->|SCA| BANKID[BankID]
API -->|Remittance corridors| CORRIDOR[30+ countries]
2. Actors & Personas
| Usability | Should Have | John (Designer) | ||
| Compatibility | 4 | Must Have | John | |
| Maintainability | 5 | Should Have | John | |
| Compliance | 8 | Critical | John + Legal | |
| Data | 5 | Must Have | John |
Persona Detail
Persona: Amir (Consumer)
Role:Software developer, immigrant from BosniaGoal:Send 3,000 NOK/month to his mother in Sarajevo cheaply and reliably; also pay at Ahmet's kebab shopPain Points:Western Union charges 10%; needs 2 separate apps for remittance and local paymentsTech Savviness:HighFrequency of Use:Weekly (remittance monthly; QR payments weekly)
Persona: Ahmet (Merchant)
Role:Owner of kebab shop in OsloGoal:Accept payments without Vipps terminal; lower fees; understand daily revenuePain Points:Vipps charges 1.75-2.75%; requires hardware terminal; fees eat into marginsTech Savviness:MediumFrequency of Use:Daily (receives 20-50 QR payments/day)
3.2. FunctionalPerformance Requirements
3.1 Module: Authentication & BankID Onboarding
Module Overview
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: User Registration (3-step onboarding)
| Metric | Target | Measurement Conditions | Method | Priority | ||
|---|---|---|---|---|---|---|
| Time | ||||||
| 4G connection, cold cache | Lighthouse | Must Have | ||||
| p95
Description: New users register via a 3-step flow: (1) personal details + BankID, (2) OTP verification via Norwegian phone number, (3) PIN setup. Users must be ≥18 years old (validated via BankID DOB). Norwegian phone (+47) required.
Acceptance Criteria:
Givena valid email, password (≥8 chars), Norwegian phone (+47), and DOB ≥18 years,whenuser submits registration,thenaccount is created and user proceeds to OTP stepGivena user under 18 years old,whenthey submit registration,thensystem rejects with "Du må være minst 18 år"Givenan already-registered email,whenuser tries to register,thensystem returns 409 "Email already in use"GivenOTP is sent,whenuser enters correct 6-digit code,thenuser proceeds to PIN setupGivenPIN setup,whenuser enters and confirms 4-digit PIN,thenaccount is activatedGiveninvalid email format,whenuser submits,then422 validation error with specific field details
Data Requirements:
Input: email (unique), password (≥8 chars), first_name, last_name, phone (+47), date_of_birthOutput: user record (id, kyc_status=pending), JWT token in httpOnly cookieValidation: email format (regex), password length, phone format, DOB ≥18
Business Rules: RUL-001, RUL-002, RUL-008
Dependencies: None
FR-002: User Login
| Normal | |
| Must Have | |
|
Description: Users log in with email + password. JWT token issued in httpOnly cookie (7-day expiry). Failed logins rate-limited.
Acceptance Criteria:
Givenvalid email + password,whenuser submits login,thenJWT cookie set and user redirected to dashboardGiveninvalid credentials,whenuser submits,then401 "Invalid email or password" (no user enumeration)Given10+ attempts from same IP in 1 minute,whenuser tries again,then429 rate limitp95 responseGivenauthenticated session idle for 7 days,whenuser makes request,thentoken expired; redirect to login
Data Requirements:
Input: email, passwordOutput: 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
| Normal | |
| Must Have | |
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:
Givenauthenticated user,whenthey call GET /api/auth/me,thencurrent user object returnedGivenunauthenticated user,whenthey access protected route,then401 UnauthorizedGivenauthenticated user,whenthey POST /api/auth/logout,thencookie 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
| < | ||
| api-benchmarks.test.ts | Must Have | |
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:
Givenuser with kyc_status=pending,whenthey attempt remittance,then403 "KYC verification required" with link to completeGivenapproved user,whenthey initiate transaction,thentransaction proceedsGivenSumsub webhook callback with approved status,whenreceived,thenuser kyc_status updated to approvedGivenrejected user,whenthey attempt transaction,then403 with rejection reason
Business Rules: RUL-008
Dependencies: FR-001
3.3 Module: Remittance (Send Money)
Module Overview
Core revenueWeb streamVitals: #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
| < | |||||
| Lighthouse | Must Have | ||||
|
< 2,000ms total | 50 concurrent calls | api-benchmarks.test.ts | Should Have |
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:
Givenauthenticated + KYC-approved user and valid recipient,whenPOST /api/transactions/remittance with amount 100-50,000 NOK,then201 transaction created; fee calculated as amount × 0.005Givenunauthenticated user,whenthey attempt remittance,then401 UnauthorizedGivenuser with insufficient balance,whenthey attempt remittance,then402 "Insufficient balance"Givenamount below 100 NOK or above 50,000 NOK,whenuser submits,then400 validation errorGivenvalid transaction,whencompleted,thentransaction_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_atValidation: 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:3.
ExchangeScalability Rates
| Metric | MVP Target | Phase 2 Target | Method | Priority | ||
|---|---|---|---|---|---|---|
| Active | ||||||
| 5,000+ users (PostgreSQL) | Load testing | Must Have | ||||
Description: Current NOK exchange rates for all supported corridors. GET /api/rates returns all; GET /api/rates/[currency] returns specific rate.
Acceptance Criteria:
GivenGET /api/rates,whencalled,thenreturns all 6 NOK exchange rates (RSD, BAM, PKR, TRY, PLN, EUR)GivenGET /api/rates/RSD,whencalled,thenreturns NOK→RSD rateGivenGET /api/rates/XXX (invalid),whencalled,then404 Not FoundGivenrate query,whencurrency code is lowercase,thencase-insensitive match
Dependencies: None
FR-022: Recipients Management
| Migrate | ||
| Monitoring | Must Have | |
Description: Users can add, list, and reuse recipients for remittance. Recipients have name, country, bank account / IBAN.
Acceptance Criteria:
Givenauthenticated user,whenPOST /api/recipients with valid data,thenrecipient created and associated with userGivenauthenticated user,whenGET /api/recipients,thenall user's recipients returnedGivenIBAN provided,whenvalidated,thenreject invalid IBAN formatGivenunauthenticated user,whenaccessing recipients,then401 Unauthorized
Business Rules: RUL-003
Dependencies: FR-002
3.4 Module: 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: QR Payment — Consumer Flow
| 10 | |||||
| Rate limiter config | Must Have | ||||
|
< 1GB on Fly.io persistent volume | Managed PostgreSQL | Storage monitoring | Should Have |
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:
Givenauthenticated + KYC-approved user,whenPOST /api/transactions/qr-payment with valid merchantId and amount ≥1 NOK,then201 transaction created; merchant fee calculated as amount × 0.01Giveninvalid merchantId,whenuser pays,then404 "Merchant not found"Givenamount < 1 NOK,whensubmitted,then400 validation errorGivenmissing merchantId,whensubmitted,then400 validation errorGivensuccessful payment,whencompleted,thenboth 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 detailsValidation: 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:4.
MerchantAvailability Registration + QR Generation
| Target | Period | Exclusions | Priority | ||
|---|---|---|---|---|---|
| ≥ | |||||
| Scheduled maintenance (advance notice) | Must Have | ||||
| Max 4 hours/month | Monthly | Tue-Thu 02:00-06:00 CET preferred | Must Have | ||
|
≥ 24 hours | Per event | Emergency patches: ASAP notify | Must Have | |
| NFR-A04 | RPO (Recovery Point Objective) | Max 24 hours data loss | Per incident | Daily backup schedule | Must Have |
| NFR-A05 | RTO (Recovery Time Objective) | System restored within 4 hours | Per incident | For staging; production target 2 hours | Must Have |
| NFR-A06 | Database backup | Daily automated backup | Ongoing | Fly.io persistent volume | Must Have |
Description:SLA Merchants register their business (name, address, bank account) and receive a unique QR code. Self-service onboarding < 5 minutes.
Acceptance Criteria:
Givenauthenticated user,whenPOST /api/merchants with valid business data,thenmerchant record created with unique QR code valueGivenmerchant,whenGET /api/merchants/me,thenmerchant details + QR code returnedGivenQR code,whenscanned by Drop consumer app,thenmerchant identified and payment flow initiated
Business Rules: RUL-006
Dependencies: FR-002, FR-010
FR-032: Merchant Dashboard AnalyticsReference:
| 99.5% | 3.6 hours |
| 99.0% | 7.3 hours |
5. Security Requirements
Context: Drop is a fintech app handling real money flows. Security is Critical priority. See security/drop-security-rapport.md for full audit (score: 57/100 pre-Phase 0.5; target: 80/100 post-hardening).
| ID | Requirement | Category | Target / Standard | Method | Priority |
|---|---|---|---|---|---|
| NFR-SEC01 | Authentication | Auth | JWT (jose library) in httpOnly cookie; SameSite=Strict; 7-day expiry | Code review + audit | Must Have |
| NFR-SEC02 | Password hashing | Auth | bcrypt, 12 rounds; NO SHA-256 fallback | auth.test.ts | Must Have |
| NFR-SEC03 | JWT secret | Secrets | JWT_SECRET must be set via env var — fail fast if missing | Code review | Must Have |
| NFR-SEC04 | CSRF protection | Injection | CSRF middleware on all POST/PATCH/DELETE endpoints | Code review + test | Must Have |
| NFR-SEC05 | Rate limiting | Abuse | 10 req/min on auth; 60/min general; persistent (DB-backed, not in-memory) | middleware.test.ts | Must Have |
| NFR-SEC06 | Input validation | Injection | All inputs sanitized server-side; parameterized SQL (no raw queries) | validation.test.ts | Must Have |
| NFR-SEC07 | XSS prevention | Injection | CSP headers (script-src 'self'); no dangerouslySetInnerHTML | OWASP ZAP | Must Have |
| NFR-SEC08 | Security headers | HTTP | HSTS, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, CSP | securityheaders.com | Must Have |
| NFR-SEC09 | Card data | PCI-DSS | NEVER store or return full card number or CVV; only last_four + token_ref | Code review + db.test.ts | Must Have |
| NFR-SEC10 | Audit logging | Compliance | All auth events, transactions, KYC changes logged with user_id + IP + timestamp | Code review | Must Have |
| NFR-SEC11 | Per-user transaction locks | Financial | Concurrent transactions from same user serialised; no double-spend | Integration test | Must Have |
| NFR-SEC12 | Penetration testing | Operations | External pentest before production launch | Third-party report | Should Have |
6. Reliability Requirements
| ID | Requirement | Metric | Target | Method | Priority |
|---|---|---|---|---|---|
| NFR-R01 | Application error rate | 5xx errors / total requests | < 0.1% | Monitoring | Must Have |
| NFR-R02 | Transaction integrity | Atomic transactions | ACID compliance; no partial updates | db.test.ts | Must Have |
| NFR-R03 | MTTR | Average recovery time | < 4 hours | Incident log | Must Have |
| NFR-R04 | Data integrity | Database constraints | Zero orphaned records; FK constraints enabled | db.test.ts | Must Have |
| NFR-R05 | Health check | System observability | GET /api/health returns 200 with DB status | CI smoke tests | Must Have |
7. Usability Requirements
| ID | Requirement | Target | Method | Priority |
|---|---|---|---|---|
| NFR-U01 | Onboarding completion | New user completes onboarding (3 steps) in < 3 minutes | Usability testing | Must Have |
| NFR-U02 | Remittance flow time | Registered user sends money in < 2 minutes | Usability testing | Must Have |
| NFR-U03 | Mobile responsiveness | Fully functional on 375px–1440px (primary: 375-428px mobile) | Manual + automated | Must Have |
| NFR-U04 | Error recovery | User can recover from any form error without page reload | Manual testing | Must Have |
| NFR-U05 | Language | Norwegian (primary) and English (secondary) | Content audit | Should Have |
8. Compatibility Requirements
| ID | Requirement | Category | Target | Priority |
|---|---|---|---|---|
| NFR-C01 | Web browsers | Browser | Chrome 100+, Firefox 100+, Safari 16+, Edge 100+ | Must Have |
| NFR-C02 | Mobile browsers | Browser | Safari iOS 15+, Chrome Android 100+ (primary platform) | Must Have |
| NFR-C03 | Screen resolutions | Responsive | 375px (iPhone SE) to 1440px (desktop); mobile-first | Must Have |
| NFR-C04 | API versioning | API | Next.js API Routes (no versioning in MVP); semantic versioning in Phase 2 | Should Have |
9. Maintainability Requirements
| ID | Requirement | Metric | Target | Method | Priority |
|---|---|---|---|---|---|
| NFR-M01 | Test coverage | % code covered | ≥ 80% overall; 100% for auth + transaction paths | CI coverage (Vitest) | Must Have |
| NFR-M02 | CI/CD pipeline | Deployment frequency | Bug fix to staging in < 30 minutes from merge | GitHub Actions | Must Have |
| NFR-M03 | Feature flags | Feature control | All gated features controllable via env vars without redeploy | feature-flags.test.ts | Should Have |
Description: Merchants view transaction volume, revenue, and fees by time period (today/week/month).
Acceptance Criteria:
Givenauthenticated merchant,whenGET /api/merchants/dashboard?period=week,thentotal transactions, gross volume, fees earned returnedGiveninvalid period,whenqueried,thendefaults 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
| All | ||||
| Should Have | ||||
|
0 critical CVEs in production dependencies | npm audit in CI | Must Have |
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:
Givenauthenticated user,whenGET /api/bank-accounts,thenlinked bank account(s) with masked account number and balance returnedGivenuser with no linked account,whenviewing accounts,thenprompt to link bank via BankID
Business Rules: RUL-003
Dependencies: FR-002, FR-010
3.610. Module:Compliance Transaction History
Module Overview
Users view all their transactions (remittance, QR payments) with filters by type, date, status.
FR-050: Transaction History
| Applicability | Requirement | Technical Implementation | Priority | ||
|---|---|---|---|---|---|
| Yes — Norwegian users | Lawful basis; right to deletion; DPA with BaaS; 72h breach notification | Data deletion API; audit logs; DPA contract | Must Have | ||
| GDPR — Data minimisation | Yes | Collect only data necessary for stated purpose | BA review of DB schema | Must Have | |
| NFR-COMP03 | PSD2 (EU) | Yes — payment initiation | PISP/AISP registration with Finanstilsynet; or operate under bank partner licence | Finanstilsynet registration | Must Have |
| NFR-COMP04 | AML / AMLD6 | Yes — money transfer | KYC verification before transaction; transaction monitoring; SAR capability | Sumsub integration; monitoring alerts | Must Have |
| NFR-COMP05 | PCI-DSS | Partial (cards feature) | No card number/CVV storage; tokenisation only | last_four + token_ref only; tokenisation via partner | Must Have |
| NFR-COMP06 | DORA (EU) | Yes | ICT risk management; incident reporting framework | Incident report template; business continuity | Should Have |
|
Description: Authenticated users view all transactions with pagination. Filterable by type (remittance/qr_payment) and date range.
Acceptance Criteria:
Givenauthenticated user,whenGET /api/transactions,thenall user's transactions returned (most recent first)Givenquery params,when?type=remittance,thenfiltered results returnedGivenunauthenticated user,whenaccessing transactions,then401 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
| Must Have | ||
| Yes | ||
| NEVER use "banking" without licence disclaimer in UI | UI /learning-opportunity on violations |
|
Description: Users receive push notifications when transactions are created or completed. Notifications stored in DB and viewable in-app.
Acceptance Criteria:
Givenauthenticated user,whenGET /api/notifications,thenall user's notifications returned (unread first)Givennew transaction,whencompleted,thennotification record created for relevant user(s)Givenuser marks notification as read,whenPATCH /api/notifications/[id],thenstatus 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
|
Description: Authenticated users view their profile details, update preferences, and initiate account deletion (GDPR right to erasure).
Acceptance Criteria:
Givenauthenticated user,whenGET /api/auth/me,thenuser profile returned (no password hash)Givenauthenticated user,whenDELETE /api/user/account,thenaccount 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
Description: 8 feature flags control access to Cards (feature-flagged), Top-up (removed), and other future features. Controlled via environment variables.
Acceptance Criteria:
GivenFF_CARDS_ENABLED=false,whenuser accesses /cards,then404-equivalent feature gate responseGivenFF_CARDS_ENABLED=true,whenuser accesses /cards,thenfull cards feature accessibleGivenGET /api/feature-flags,whencalled,thenall 8 flags with current values returned
Business Rules: Cards feature requires card partner agreement (RUL-010)
Dependencies: None
4. Use Case Diagrams
4.1 Consumer User Use Cases
graph LR
A1((Consumer)) --> UC1[FR-001: Register via BankID]
A1 --> UC2[FR-002: Login]
A1 --> UC3[FR-020: 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-060: Receive Payment Notifications]
5. System Behavior Specifications
5.1 Error Handling
All errors return{error, message, details?}JSON formatValidation errors: 422 withdetailsarray listing per-field errorsAuthentication errors: 401 (never reveal if email exists)Rate limit errors: 429 with Retry-After headerNo stack traces in production responses
5.211. Data Persistence
All mutations logged with user_id, ip, timestampTransaction records are immutable once created (status-only updates)ACID compliance required for financial transactions
5.3 Session & State
JWT expiry: 7 dayshttpOnly cookies (SameSite=Strict) prevent XSS token theftCSRF protection on all state-changing endpoints (POST/PATCH/DELETE)
5.4 Notifications
In-app: all transaction events (create, complete, fail)Push: Phase 2 (requires native mobile app)Email: account registration, security alerts
5.5 Security Headers (Required)
HSTS, CSP, X-Frame-Options: DENY, X-Content-Type-Options: nosniffReferrer-Policy: strict-origin-when-cross-origin
6. Requirements Summary Table
| ID | Target | Implementation | Priority | ||||
|---|---|---|---|---|---|---|---|
| Data retention — user data | Retention | User |
Must Have | ||||
| Audit logs: 5 years (AML requirement) | Log rotation policy | Must Have | |||||
| All PII fields identified in DATABASE-SCHEMA.md | Data dictionary in docs/backend/ | Must Have | |||||
| No real user data in staging/dev environments | Seed data only; no prod data migration | Must Have | |||||
| Should Have | |||||||
Requirements Count:
Must Have: 7Should Have: 8Could Have: 0Won't Have (this release): Cards virtual/physical (BR-014), Loyalty rewards (BR-012)
7.12. TraceabilityNFR toTesting Business& RequirementsVerification Plan
| Pass |
||||
|---|---|---|---|---|
| All NFR-P targets met | ||||
| Score ≥ 80/100; no critical open | ||||
| ≥ 99.5% monthly | ||||
| All compliance items verified | ||||
Full traceability matrix:[requirements-traceability-matrix.md](requirements-traceability-matrix.md)
Approval
| Role | Name | Date | Signature |
|---|---|---|---|
| Author | John (AI Director) | 2026-02-23 | Approved (AI) |
| Tech Lead | John | 2026-02-23 | Approved |
| AI Director (John) | John | 2026-02-23 | Approved |
| CEO (Alem) | Alem Bašić | TBD |